Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #129666 > unrolled thread
| Started by | Dan Purgert <dan@djph.net> |
|---|---|
| First post | 2018-04-24 13:39 +0000 |
| Last post | 2018-04-27 00:23 -0700 |
| Articles | 20 on this page of 131 — 31 participants |
Back to article view | Back to comp.lang.c
Need some help getting to my feet Dan Purgert <dan@djph.net> - 2018-04-24 13:39 +0000
Re: Need some help getting to my feet Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-04-24 16:38 +0100
Re: Need some help getting to my feet Real Troll <real.troll@trolls.com> - 2018-04-24 13:40 -0400
Re: Need some help getting to my feet Tim Rentsch <txr@alumni.caltech.edu> - 2018-04-24 08:38 -0700
[Solved] Need some help getting to my feet Dan Purgert <dan@djph.net> - 2018-04-24 18:06 +0000
Re: [Solved] Need some help getting to my feet Tim Rentsch <txr@alumni.caltech.edu> - 2018-04-25 07:33 -0700
Re: [Solved] Need some help getting to my feet Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-25 07:49 -0700
Re: [Solved] Need some help getting to my feet Dan Purgert <dan@djph.net> - 2018-04-25 21:28 +0000
Re: [Solved] Need some help getting to my feet antispam@math.uni.wroc.pl - 2018-04-28 14:26 +0000
Re: [Solved] Need some help getting to my feet Dan Purgert <dan@djph.net> - 2018-04-28 20:25 +0000
Re: [Solved] Need some help getting to my feet antispam@math.uni.wroc.pl - 2018-04-29 15:12 +0000
Re: [Solved] Need some help getting to my feet bartc <bc@freeuk.com> - 2018-04-29 16:49 +0100
Re: [Solved] Need some help getting to my feet antispam@math.uni.wroc.pl - 2018-04-30 15:30 +0000
Re: [Solved] Need some help getting to my feet bartc <bc@freeuk.com> - 2018-04-30 17:06 +0100
Re: [Solved] Need some help getting to my feet Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-30 09:12 -0700
Re: [Solved] Need some help getting to my feet C W Rose <cwr@seckford.org> - 2018-05-02 15:19 +0100
Re: [Solved] Need some help getting to my feet Steven Petruzzellis <frelwizzen@gmail.com> - 2018-05-02 07:54 -0700
Re: [Solved] Need some help getting to my feet Dan Purgert <dan@djph.net> - 2018-05-03 12:45 +0000
Re: [Solved] Need some help getting to my feet antispam@math.uni.wroc.pl - 2018-05-05 14:22 +0000
Re: [Solved] Need some help getting to my feet Steve Carroll <frelwizzen@gmail.com> - 2018-05-05 08:42 -0700
Re: [Solved] Need some help getting to my feet C W Rose <cwr@seckford.org> - 2018-05-07 16:34 +0100
Re: [Solved] Need some help getting to my feet Steve Carroll <frelwizzen@gmail.com> - 2018-05-07 09:37 -0700
Re: [Solved] Need some help getting to my feet Wouter Verhelst <w@uter.be> - 2018-05-04 10:19 +0200
Re: [Solved] Need some help getting to my feet bartc <bc@freeuk.com> - 2018-05-04 11:31 +0100
Re: [Solved] Need some help getting to my feet Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-29 08:53 -0700
Re: [Solved] Need some help getting to my feet Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-29 18:14 -0700
Re: [Solved] Need some help getting to my feet Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-04-25 08:54 -0700
Re: [Solved] Need some help getting to my feet Keith Thompson <kst-u@mib.org> - 2018-04-25 09:24 -0700
Re: [Solved] Need some help getting to my feet bartc <bc@freeuk.com> - 2018-04-25 18:10 +0100
Re: [Solved] Need some help getting to my feet Keith Thompson <kst-u@mib.org> - 2018-04-25 10:48 -0700
Casting the return value of malloc() (Was: [Solved] Need some help getting to my feet) gazelle@shell.xmission.com (Kenny McCormack) - 2018-04-25 19:23 +0000
Re: Casting the return value of malloc() (Was: [Solved] Need some help getting to my feet) Bruce S <bruces42@hotmail.com> - 2018-04-25 16:55 -0600
Re: Casting the return value of malloc() (Was: [Solved] Need some help getting to my feet) "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-04-25 16:03 -0700
Re: Casting the return value of malloc() (Was: [Solved] Need some help getting to my feet) Bruce S <bruces42@hotmail.com> - 2018-04-25 18:02 -0600
Re: Casting the return value of malloc() (Was: [Solved] Need some help getting to my feet) "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-04-25 17:14 -0700
Re: Casting the return value of malloc() (Was: [Solved] Need some help getting to my feet) Bruce S <bruces42@hotmail.com> - 2018-04-26 13:31 -0600
Re: Casting the return value of malloc() (Was: [Solved] Need some help getting to my feet) gazelle@shell.xmission.com (Kenny McCormack) - 2018-04-26 03:27 +0000
Re: Casting the return value of malloc() (Was: [Solved] Need some help getting to my feet) Dan Purgert <dan@djph.net> - 2018-04-26 11:06 +0000
Re: [Solved] Need some help getting to my feet 1alvinalbrecht1@gmail.com - 2018-04-25 18:41 -0700
Re: [Solved] Need some help getting to my feet Keith Thompson <kst-u@mib.org> - 2018-04-26 07:26 -0700
Re: [Solved] Need some help getting to my feet Spiros Bousbouras <spibou@gmail.com> - 2018-04-25 16:26 +0000
Re: [Solved] Need some help getting to my feet Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-04-25 21:50 +0100
Re: [Solved] Need some help getting to my feet Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-04-26 01:47 -0700
Re: [Solved] Need some help getting to my feet Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-26 02:18 -0700
Re: [Solved] Need some help getting to my feet Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-04-26 11:18 +0100
Re: [Solved] Need some help getting to my feet bartc <bc@freeuk.com> - 2018-04-26 11:33 +0100
Re: [Solved] Need some help getting to my feet Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-26 05:26 -0700
Re: [Solved] Need some help getting to my feet Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-04-27 00:09 +0100
Re: [Solved] Need some help getting to my feet Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-04-26 09:14 -0700
Re: [Solved] Need some help getting to my feet Keith Thompson <kst-u@mib.org> - 2018-04-26 10:26 -0700
Re: [Solved] Need some help getting to my feet Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-04-27 00:02 +0100
Re: [Solved] Need some help getting to my feet Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-04-27 02:35 -0700
Re: [Solved] Need some help getting to my feet Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-04-27 11:34 +0100
Re: [Solved] Need some help getting to my feet mark.bluemel@gmail.com - 2018-04-27 04:14 -0700
STDIO.H vs stdio.h (Was: [Solved] Need some help getting to my feet) gazelle@shell.xmission.com (Kenny McCormack) - 2018-04-27 13:08 +0000
Re: STDIO.H vs stdio.h (Was: [Solved] Need some help getting to my feet) Manfred <noname@invalid.add> - 2018-04-27 18:52 +0200
Re: [Solved] Need some help getting to my feet Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-27 07:08 -0700
Re: [Solved] Need some help getting to my feet Keith Thompson <kst-u@mib.org> - 2018-04-27 10:36 -0700
Re: [Solved] Need some help getting to my feet bartc <bc@freeuk.com> - 2018-04-27 19:04 +0100
Re: [Solved] Need some help getting to my feet Keith Thompson <kst-u@mib.org> - 2018-04-27 11:26 -0700
Re: [Solved] Need some help getting to my feet scott@slp53.sl.home (Scott Lurndal) - 2018-04-27 18:45 +0000
Re: [Solved] Need some help getting to my feet Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-04-30 03:43 -0700
Re: [Solved] Need some help getting to my feet Keith Thompson <kst-u@mib.org> - 2018-04-30 09:10 -0700
Re: [Solved] Need some help getting to my feet Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-30 23:32 -0700
Re: [Solved] Need some help getting to my feet Keith Thompson <kst-u@mib.org> - 2018-04-26 07:33 -0700
Re: [Solved] Need some help getting to my feet jameskuyper@verizon.net - 2018-04-26 08:38 -0700
Re: [Solved] Need some help getting to my feet already5chosen@yahoo.com - 2018-04-27 03:30 -0700
Re: [Solved] Need some help getting to my feet Tim Rentsch <txr@alumni.caltech.edu> - 2018-04-27 08:41 -0700
Re: [Solved] Need some help getting to my feet Dan Purgert <dan@djph.net> - 2018-04-27 17:04 +0000
Re: [Solved] Need some help getting to my feet Keith Thompson <kst-u@mib.org> - 2018-04-27 11:06 -0700
Re: [Solved] Need some help getting to my feet Dan Purgert <dan@djph.net> - 2018-04-27 20:15 +0000
Re: [Solved] Need some help getting to my feet Keith Thompson <kst-u@mib.org> - 2018-04-27 13:47 -0700
Re: [Solved] Need some help getting to my feet bartc <bc@freeuk.com> - 2018-04-27 22:06 +0100
Re: [Solved] Need some help getting to my feet Keith Thompson <kst-u@mib.org> - 2018-04-27 14:51 -0700
Re: [Solved] Need some help getting to my feet bartc <bc@freeuk.com> - 2018-04-28 00:25 +0100
Re: [Solved] Need some help getting to my feet Keith Thompson <kst-u@mib.org> - 2018-04-27 17:23 -0700
Re: [Solved] Need some help getting to my feet bartc <bc@freeuk.com> - 2018-04-28 01:39 +0100
Re: [Solved] Need some help getting to my feet Keith Thompson <kst-u@mib.org> - 2018-04-27 19:22 -0700
Re: [Solved] Need some help getting to my feet Wouter Verhelst <w@uter.be> - 2018-05-04 10:36 +0200
Re: [Solved] Need some help getting to my feet bartc <bc@freeuk.com> - 2018-05-04 11:21 +0100
Re: [Solved] Need some help getting to my feet Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-05-04 04:03 -0700
Re: [Solved] Need some help getting to my feet David Brown <david.brown@hesbynett.no> - 2018-05-04 14:03 +0200
Re: [Solved] Need some help getting to my feet Keith Thompson <kst-u@mib.org> - 2018-05-04 09:19 -0700
Re: [Solved] Need some help getting to my feet Keith Thompson <kst-u@mib.org> - 2018-05-04 11:00 -0700
Re: [Solved] Need some help getting to my feet David Brown <david.brown@hesbynett.no> - 2018-05-05 18:39 +0200
Re: [Solved] Need some help getting to my feet Steve Carroll <frelwizzen@gmail.com> - 2018-05-07 16:23 -0700
Re: [Solved] Need some help getting to my feet Dan Purgert <dan@djph.net> - 2018-04-28 12:11 +0000
Re: [Solved] Need some help getting to my feet luser droog <luser.droog@gmail.com> - 2018-04-27 14:12 -0700
Re: [Solved] Need some help getting to my feet Dan Purgert <dan@djph.net> - 2018-04-28 12:21 +0000
Re: [Solved] Need some help getting to my feet Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-05-04 13:31 +0000
Re: [Solved] Need some help getting to my feet luser droog <luser.droog@gmail.com> - 2018-05-04 17:19 -0700
Re: [Solved] Need some help getting to my feet Tim Rentsch <txr@alumni.caltech.edu> - 2018-05-18 21:55 -0700
Re: [Solved] Need some help getting to my feet already5chosen@yahoo.com - 2018-05-21 03:26 -0700
Re: [Solved] Need some help getting to my feet Tim Rentsch <txr@alumni.caltech.edu> - 2018-06-14 03:00 -0700
Mixing declarations and statements in C code (Was: [Solved] Need some help getting to my feet) gazelle@shell.xmission.com (Kenny McCormack) - 2018-12-26 06:43 +0000
Re: [Solved] Need some help getting to my feet Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-12-26 19:02 +0300
Re: [Solved] Need some help getting to my feet Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-12-31 18:01 +0000
Re: [Solved] Need some help getting to my feet Richard Damon <Richard@Damon-Family.org> - 2018-12-31 17:16 -0500
Re: [Solved] Need some help getting to my feet Bart <bc@freeuk.com> - 2018-12-31 22:44 +0000
Re: [Solved] Need some help getting to my feet Ike Naar <ike@iceland.freeshell.org> - 2019-01-01 19:14 +0000
Re: [Solved] Need some help getting to my feet rbowman <bowman@montana.com> - 2019-01-01 13:14 -0700
Re: [Solved] Need some help getting to my feet Keith Thompson <kst-u@mib.org> - 2019-01-01 12:49 -0800
Re: [Solved] Need some help getting to my feet rbowman <bowman@montana.com> - 2019-01-01 15:55 -0700
Re: [Solved] Need some help getting to my feet Keith Thompson <kst-u@mib.org> - 2019-01-01 16:05 -0800
Re: [Solved] Need some help getting to my feet rbowman <bowman@montana.com> - 2019-01-01 22:17 -0700
Re: [Solved] Need some help getting to my feet Bart <bc@freeuk.com> - 2019-01-01 20:25 +0000
Re: [Solved] Need some help getting to my feet Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-05-04 11:48 +0000
Re: Need some help getting to my feet Ed Kellett <e@kellett.im> - 2018-04-24 16:40 +0100
Re: Need some help getting to my feet Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-24 11:01 -0700
Re: Need some help getting to my feet Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-04-24 15:50 +0000
Re: Need some help getting to my feet Spiros Bousbouras <spibou@gmail.com> - 2018-04-24 17:21 +0000
Re: Need some help getting to my feet Real Troll <real.troll@trolls.com> - 2018-04-24 13:20 -0400
Re: Need some help getting to my feet Real Troll <real.troll@trolls.com> - 2018-04-24 13:30 -0400
Re: Need some help getting to my feet Spiros Bousbouras <spibou@gmail.com> - 2018-04-24 17:42 +0000
Re: Need some help getting to my feet Dan Purgert <dan@djph.net> - 2018-04-24 18:26 +0000
Re: Need some help getting to my feet Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-04-25 19:19 +0000
Re: Need some help getting to my feet Dan Purgert <dan@djph.net> - 2018-04-25 21:30 +0000
Re: Need some help getting to my feet bartc <bc@freeuk.com> - 2018-04-25 22:55 +0100
Re: Need some help getting to my feet Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-04-27 08:49 +0000
Re: Need some help getting to my feet Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-04-25 15:37 +0000
Re: Need some help getting to my feet Keith Thompson <kst-u@mib.org> - 2018-04-25 09:27 -0700
Re: Need some help getting to my feet Wouter Verhelst <w@uter.be> - 2018-04-26 13:22 +0200
Re: Need some help getting to my feet Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-26 09:21 -0700
Re: Need some help getting to my feet Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-04-27 08:16 +0000
Re: Need some help getting to my feet Tim Rentsch <txr@alumni.caltech.edu> - 2018-04-27 09:36 -0700
Re: Need some help getting to my feet Wouter Verhelst <w@uter.be> - 2018-05-04 10:41 +0200
Re: Need some help getting to my feet Spiros Bousbouras <spibou@gmail.com> - 2018-04-28 14:27 +0000
Re: Need some help getting to my feet Keith Thompson <kst-u@mib.org> - 2018-04-24 11:09 -0700
Re: Need some help getting to my feet C W Rose <cwr@seckford.org> - 2018-04-25 18:59 +0100
Re: Need some help getting to my feet Keith Thompson <kst-u@mib.org> - 2018-04-26 10:42 -0700
Re: Need some help getting to my feet Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-27 00:23 -0700
Page 2 of 7 — ← Prev page 1 [2] 3 4 5 6 7 Next page →
| From | C W Rose <cwr@seckford.org> |
|---|---|
| Date | 2018-05-07 16:34 +0100 |
| Subject | Re: [Solved] Need some help getting to my feet |
| Message-ID | <m986se-b8j.ln1@tanner.seckford.org> |
| In reply to | #130234 |
antispam@math.uni.wroc.pl wrote:
> C W Rose <cwr@seckford.org> wrote:
>>
>> The avr-gcc related binaries are about 4M, and the AVR C library
>> about 17M; that includes all the 8-bit AVR variants.
>
> You must be writing about some old/restricted version. Let
> me reiterate: the 140 MB above is just GNU toolchain. AFAIK
> Arduino uses generic C + C++ toolchain with no modifications.
> Arduino libraries are separate and I did not count them
> (the whole Arduino stuff adds another 270 MB). In more detail:
>
> ls -s /opt/arduino-1.6.7/hardware/tools/avr/libexec/gcc/avr/4.8.1/
> razem 29064
> 9232 cc1 4 liblto_plugin.la 8596 lto1
> 10248 cc1plus 0 liblto_plugin.so 532 lto-wrapper
> 360 collect2 0 liblto_plugin.so.0 4 plugin
> 4 install-tools 84 liblto_plugin.so.0.0.0
>
> so C compiler cc1 is 9.2MB, if you want whole program optimization
> you need another 8.5 MB for lto1. You can skip 10MB for cc1plus.
>
> Then there is 19MB for compiler drivers, binutils, gdb and avr
> tools:
>
> ls -s /opt/arduino-1.6.7/hardware/tools/avr/bin/
> razem 19260
> 572 avr-addr2line 28 avr-elfedit 3800 avr-gdb 600 avr-ranlib
> 600 avr-ar 740 avr-g++ 644 avr-gprof 404 avr-readelf
> 824 avr-as 736 avr-gcc 1020 avr-ld 604 avr-run
> 740 avr-c++ 736 avr-gcc-4.8.1 1020 avr-ld.bfd 584 avr-size
> 568 avr-c++filt 28 avr-gcc-ar 4 avr-man 572 avr-strings
> 736 avr-cpp 28 avr-gcc-nm 584 avr-nm 752 avr-strip
> 4 avrdude 28 avr-gcc-ranlib 752 avr-objcopy 4 libusb-config
> 372 avrdude_bin 304 avr-gcov 872 avr-objdump
>
> 18MB is taken by include files (they contain documentation so are
> much larger than minimal possible incude files). Toolchain contains
> 16 variants of libgcc.a, each about 3.2MB. I looked at one
> variant. There are about 900 routines in library totaling about
> 90 kB, but presumably metadata (and possibly debug info) blow up
> space to more than 3 MB. AFAICS routines deal mostly with
> arithmetic (IIUC among other they provide software implementation
> of single precision floating point).
>
I get these numbers for a _C_ installation:
$ cd /usr/i686-pc-linux-gnu
gnu $ du -h avr
1.8M avr/gcc-bin/4.7.3
1.8M avr/gcc-bin
4.0K avr/lib
2.2M avr/binutils-bin/2.23.2
2.2M avr/binutils-bin
4.0M avr
$ cd /usr
usr $ du -h avr
12K avr/etc/portage
16K avr/etc
448K avr/lib/avrxmega6
364K avr/lib/avrxmega5
396K avr/lib/avrxmega2
400K avr/lib/avr3
676K avr/lib/avr25
348K avr/lib/avr6
552K avr/lib/avr4
1.5M avr/lib/avr5
408K avr/lib/avr35
356K avr/lib/avr31
432K avr/lib/avr51
364K avr/lib/avrxmega7
360K avr/lib/avrxmega4
7.1M avr/lib
20K avr/include/compat
7.6M avr/include/avr
64K avr/include/util
7.9M avr/include
15M avr
However, I missed these two the first time around:
$ cd /usr/lib/gcc
gcc $ du -h avr
220K avr/4.7.3/avrxmega6
228K avr/4.7.3/avrxmega5
220K avr/4.7.3/avrxmega2
216K avr/4.7.3/tiny-stack
16K avr/4.7.3/include-fixed
220K avr/4.7.3/avr3
212K avr/4.7.3/avr25/tiny-stack
428K avr/4.7.3/avr25
220K avr/4.7.3/avr6
216K avr/4.7.3/avr4
216K avr/4.7.3/avr5
216K avr/4.7.3/avr35
220K avr/4.7.3/avr31
220K avr/4.7.3/avr51
228K avr/4.7.3/avrxmega7
100K avr/4.7.3/include
8.0K avr/4.7.3/plugin/include/java
44K avr/4.7.3/plugin/include/config/avr
76K avr/4.7.3/plugin/include/config
284K avr/4.7.3/plugin/include/cp
80K avr/4.7.3/plugin/include/c-family
8.0K avr/4.7.3/plugin/include/objc
12K avr/4.7.3/plugin/include/ada/gcc-interface
16K avr/4.7.3/plugin/include/ada
3.8M avr/4.7.3/plugin/include
4.4M avr/4.7.3/plugin
220K avr/4.7.3/avrxmega4
7.9M avr/4.7.3
7.9M avr
$ cd /usr/libexec/gcc
gcc $ du -h avr
160K avr/4.7.3/plugin
23M avr/4.7.3
23M avr
For a total of 49.9 MB. I don't think there are any overlaps, but with several
AVR compilers on the system and a lot of linked files things can get a bit
mixed up. Note that this doesn't include any of the extensive documentation.
Will
--
"Facts are meaningless. You could use facts to prove anything that's
even remotely true."
Homer Simpson
[toc] | [prev] | [next] | [standalone]
| From | Steve Carroll <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-05-07 09:37 -0700 |
| Subject | Re: [Solved] Need some help getting to my feet |
| Message-ID | <dbff354d-374d-4aa0-8dae-a848855d6134@googlegroups.com> |
| In reply to | #130319 |
On Monday, May 7, 2018 at 8:35:18 AM UTC-7, C W Rose wrote: > antispam@math.uni.wroc.pl wrote: > > C W Rose <cwr@seckford.org> wrote: > >> > >> The avr-gcc related binaries are about 4M, and the AVR C library > >> about 17M; that includes all the 8-bit AVR variants. > > > > You must be writing about some old/restricted version. Let > > me reiterate: the 140 MB above is just GNU toolchain. AFAIK > > Arduino uses generic C + C++ toolchain with no modifications. > > Arduino libraries are separate and I did not count them > > (the whole Arduino stuff adds another 270 MB). In more detail: > > > > ls -s /opt/arduino-1.6.7/hardware/tools/avr/libexec/gcc/avr/4.8.1/ > > razem 29064 > > 9232 cc1 4 liblto_plugin.la 8596 lto1 > > 10248 cc1plus 0 liblto_plugin.so 532 lto-wrapper > > 360 collect2 0 liblto_plugin.so.0 4 plugin > > 4 install-tools 84 liblto_plugin.so.0.0.0 > > > > so C compiler cc1 is 9.2MB, if you want whole program optimization > > you need another 8.5 MB for lto1. You can skip 10MB for cc1plus. > > > > Then there is 19MB for compiler drivers, binutils, gdb and avr > > tools: > > > > ls -s /opt/arduino-1.6.7/hardware/tools/avr/bin/ > > razem 19260 > > 572 avr-addr2line 28 avr-elfedit 3800 avr-gdb 600 avr-ranlib > > 600 avr-ar 740 avr-g++ 644 avr-gprof 404 avr-readelf > > 824 avr-as 736 avr-gcc 1020 avr-ld 604 avr-run > > 740 avr-c++ 736 avr-gcc-4.8.1 1020 avr-ld.bfd 584 avr-size > > 568 avr-c++filt 28 avr-gcc-ar 4 avr-man 572 avr-strings > > 736 avr-cpp 28 avr-gcc-nm 584 avr-nm 752 avr-strip > > 4 avrdude 28 avr-gcc-ranlib 752 avr-objcopy 4 libusb-config > > 372 avrdude_bin 304 avr-gcov 872 avr-objdump > > > > 18MB is taken by include files (they contain documentation so are > > much larger than minimal possible incude files). Toolchain contains > > 16 variants of libgcc.a, each about 3.2MB. I looked at one > > variant. There are about 900 routines in library totaling about > > 90 kB, but presumably metadata (and possibly debug info) blow up > > space to more than 3 MB. AFAICS routines deal mostly with > > arithmetic (IIUC among other they provide software implementation > > of single precision floating point). > > > > I get these numbers for a _C_ installation: > > $ cd /usr/i686-pc-linux-gnu > gnu $ du -h avr > 1.8M avr/gcc-bin/4.7.3 > 1.8M avr/gcc-bin > 4.0K avr/lib > 2.2M avr/binutils-bin/2.23.2 > 2.2M avr/binutils-bin > 4.0M avr > > $ cd /usr > usr $ du -h avr > 12K avr/etc/portage > 16K avr/etc > 448K avr/lib/avrxmega6 > 364K avr/lib/avrxmega5 > 396K avr/lib/avrxmega2 > 400K avr/lib/avr3 > 676K avr/lib/avr25 > 348K avr/lib/avr6 > 552K avr/lib/avr4 > 1.5M avr/lib/avr5 > 408K avr/lib/avr35 > 356K avr/lib/avr31 > 432K avr/lib/avr51 > 364K avr/lib/avrxmega7 > 360K avr/lib/avrxmega4 > 7.1M avr/lib > 20K avr/include/compat > 7.6M avr/include/avr > 64K avr/include/util > 7.9M avr/include > 15M avr > > However, I missed these two the first time around: > > $ cd /usr/lib/gcc > gcc $ du -h avr > 220K avr/4.7.3/avrxmega6 > 228K avr/4.7.3/avrxmega5 > 220K avr/4.7.3/avrxmega2 > 216K avr/4.7.3/tiny-stack > 16K avr/4.7.3/include-fixed > 220K avr/4.7.3/avr3 > 212K avr/4.7.3/avr25/tiny-stack > 428K avr/4.7.3/avr25 > 220K avr/4.7.3/avr6 > 216K avr/4.7.3/avr4 > 216K avr/4.7.3/avr5 > 216K avr/4.7.3/avr35 > 220K avr/4.7.3/avr31 > 220K avr/4.7.3/avr51 > 228K avr/4.7.3/avrxmega7 > 100K avr/4.7.3/include > 8.0K avr/4.7.3/plugin/include/java > 44K avr/4.7.3/plugin/include/config/avr > 76K avr/4.7.3/plugin/include/config > 284K avr/4.7.3/plugin/include/cp > 80K avr/4.7.3/plugin/include/c-family > 8.0K avr/4.7.3/plugin/include/objc > 12K avr/4.7.3/plugin/include/ada/gcc-interface > 16K avr/4.7.3/plugin/include/ada > 3.8M avr/4.7.3/plugin/include > 4.4M avr/4.7.3/plugin > 220K avr/4.7.3/avrxmega4 > 7.9M avr/4.7.3 > 7.9M avr > > $ cd /usr/libexec/gcc > gcc $ du -h avr > 160K avr/4.7.3/plugin > 23M avr/4.7.3 > 23M avr > > For a total of 49.9 MB. I don't think there are any overlaps, but with several > AVR compilers on the system and a lot of linked files things can get a bit > mixed up. Note that this doesn't include any of the extensive documentation. > > Will > > -- > "Facts are meaningless. You could use facts to prove anything that's > even remotely true." > Homer Simpson These posts are clearly NOT automated, they are made by a glue sniffing insomniac with an axe to grind who has way too much time on his hands (and possibly has other trolls helping him). michaelunowho asked to be rated according to objective trolling criteria, which I accommodated. Robert Wessel will leave once the druggies overindulge. That and there will regularly be a temper tantrum or two in an open news group (e.g. michaelunowho). The specifics of the bullshit aside, we've all seen who usually lashes out when he does not get a response. michaelunowho failed to show a single time of a profitable business that has acquired its wealth by not giving a damn about its clients or services. I think the point is not 100% to get them to listen to him. The point is likely to piss me off for trolling outside groups he knows I frequent. -- Best CMS Solution of 2017! http://prescottcomputerguy.com Jonas Eklundh Communication AB
[toc] | [prev] | [next] | [standalone]
| From | Wouter Verhelst <w@uter.be> |
|---|---|
| Date | 2018-05-04 10:19 +0200 |
| Subject | Re: [Solved] Need some help getting to my feet |
| Message-ID | <0mhtre-p51.ln1@gangtai.grep.be> |
| In reply to | #129936 |
On 29-04-18 17:49, bartc wrote: > avr-objcopy is a 800KB program, and avrdude is 500KB (plus people know > the size of gcc/g++), so either the process is really not trivial, or it > has been somewhat over-engineered. I suspect the latter. Or, perhaps, people didn't spend any time writing their own compiler for their hardware and decided to go with code that already exists, and does what they needed (gasp).
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-05-04 11:31 +0100 |
| Subject | Re: [Solved] Need some help getting to my feet |
| Message-ID | <8EWGC.77604$7B3.29358@fx13.am4> |
| In reply to | #130127 |
On 04/05/2018 09:19, Wouter Verhelst wrote:
> On 29-04-18 17:49, bartc wrote:
>> avr-objcopy is a 800KB program, and avrdude is 500KB (plus people know
>> the size of gcc/g++), so either the process is really not trivial, or it
>> has been somewhat over-engineered. I suspect the latter.
>
> Or, perhaps, people didn't spend any time writing their own compiler for
> their hardware and decided to go with code that already exists, and does
> what they needed (gasp).
Or perhaps a compiler could be written in a couple of months of
part-time effort, and the result was a purpose-made, lightning-fast
language that would let you whizz through your work, compared with those
people using existing systems where the smallest program required
several minutes of disk-grinding before it produced a result.
That was exactly the case in the 1980s if working on microprocessor systems.
(In 2018, sometimes it seems that little has changed:
c:\cz>timeit "nasm -fwin64 mcc64.asm" # 62,000 lines
nasm -fwin64 mcc64.asm 27.83 seconds
c:\cx>timeit "mxa mcc64" # 67,000 lines
Assembling/linking mcc64.asm... to mcc64.exe
mxa mcc64 0.06 seconds
My own assembler is 500 times faster than the /existing/ assembler I'd
been using for years. (1000 times faster actually since half of that
0.06 is overheads). And this is UNOPTIMISED code.)
Funny how HPC is discussed today at the same time as people just
blithely accepting that some program might be 10 times bigger and
possibly 10 times slower than it need be.
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | Steven Petruzzellis <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-04-29 08:53 -0700 |
| Subject | Re: [Solved] Need some help getting to my feet |
| Message-ID | <a5500a2e-f5d7-4a96-a468-bc2d5b3191ff@googlegroups.com> |
| In reply to | #129935 |
On Sunday, April 29, 2018 at 8:13:03 AM UTC-7, anti...@math.uni.wroc.pl wrote: > Dan Purgert <dan@djph.net> wrote: > > antispam@math.uni.wroc.pl wrote: > > > Dan Purgert <dan@djph.net> wrote: > > >> (2) Arduino (this one's going to need a lot of specific knowledge for > > >> sure. But I really think I need a core competency in C before > > >> trying to tackle its specific stuff. > > > > > > Just for clarity: Arduino uses C++. > > > > True, the Arduino Project decided to go with C++ for their code. That > > being said, the Atmel chips that they're based on understand straight C > > as well. > > "understand straight C" is quite imprecise. Atmel chips understand their > own machine language. To program them in C you need C compiler and > supporting environment. And programming them in C works so well > that you may easily forget about complexities of the whole process. > > -- > Waldek Hebisch Of course, the sole thought that concerns dorayme is being "professional", and if he can not have that he will do more research to actively shout "others" down... ignoring him is the only option. I am happy the person you are attacking is in my kill file. Who are you even blubbering to? Who *doesn't* know that this kind of hogwash is dorayme's modus operandi, not the MO of Jonathan Rhodes? It's all just projection... the endless posting, the sock puppets, the writing of drivel, the outbursts... the false bravado and eagerness to show how distressed he is over being banned from the playground for pissing in it again. You're clueless! Ending support for command line holdovers is common sense. -- "You'll notice how quickly he loses interest when everything is about him. He clearly wants the attention" Steve Carroll, making the dumbest comment ever uttered.
[toc] | [prev] | [next] | [standalone]
| From | Steven Petruzzellis <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-04-29 18:14 -0700 |
| Subject | Re: [Solved] Need some help getting to my feet |
| Message-ID | <e3a23471-7658-4a7b-a4b8-f291354ed103@googlegroups.com> |
| In reply to | #129935 |
On Sunday, April 29, 2018 at 8:13:03 AM UTC-7, anti...@math.uni.wroc.pl wrote: > Dan Purgert <dan@djph.net> wrote: > > antispam@math.uni.wroc.pl wrote: > > > Dan Purgert <dan@djph.net> wrote: > > >> (2) Arduino (this one's going to need a lot of specific knowledge for > > >> sure. But I really think I need a core competency in C before > > >> trying to tackle its specific stuff. > > > > > > Just for clarity: Arduino uses C++. > > > > True, the Arduino Project decided to go with C++ for their code. That > > being said, the Atmel chips that they're based on understand straight C > > as well. > > "understand straight C" is quite imprecise. Atmel chips understand their > own machine language. To program them in C you need C compiler and > supporting environment. And programming them in C works so well > that you may easily forget about complexities of the whole process. > > -- > Waldek Hebisch I often defeat Donny Karcie with my thoughts. Pay for a background report on Donny Karcie and you will get proof that he was in a correctional facility last year. I do not know what for. The online reports fail to go into that extent of specificity and public records in his area are private unless court ordered. I am working on code which will show off how weak Mac is. Already moved on from that. Take it as you want! Are you being idiotic on purpose? Donny Karcie's done a pretty good job with (it appears) the Bellman–Ford algorithm to automate texts which are made to sound like a response from those of one particular legit member. It's a decades long war, and Donny Karcie is simultaneously unable to stop his trolling remarks, while posting with forgeries of William Unruh. - "You'll notice how quickly he loses interest when everything is about him. He clearly wants the attention" Steven Petruzzellis, making the dumbest comment ever uttered.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2018-04-25 08:54 -0700 |
| Subject | Re: [Solved] Need some help getting to my feet |
| Message-ID | <d04792eb-0a93-46a3-8499-ecc4377dc31d@googlegroups.com> |
| In reply to | #129678 |
On Tuesday, April 24, 2018 at 7:06:50 PM UTC+1, Dan Purgert wrote: > > Thanks Tim, Ed, Jorgen, and Ben. Given "get K&R" is the prevailing > concensus, I'll start there (maybe I'll get lucky and it's still in that > stash of programming books I kept). I think all the questions back to me > reflect Tim's above, and he had the most - so just sending this one > follow-up. > You have to be careful with the consensus. For example the consensus in this ng will be that Schild's tutorials should be avoided. That's because they contain technical errors. But that doesn't actually matter too much for a tutorial, people who don't have much experience teaching often think that teaching an error is a disaster, in fact it's often better to teach a simplification. For example void main() is an error in C (C programs must return a success / failure flag to the environment, so it should be int main()) but the vast majority of compilers accept it, and in fact the flag isn't really of any use for beginner-level programs. I'm not going to recommend against K and R. I learnt myself from the book which shipped with an early MS DOS C compiler, I forget its title. It wasn't ideal because it didn't explain what was standard and what was not, so I spent a while searching for the "fputint" function and wondered why it wasn't provided. But it was OK, I was up and running my first C programs within a few days.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-04-25 09:24 -0700 |
| Subject | Re: [Solved] Need some help getting to my feet |
| Message-ID | <ln604fi78x.fsf@kst-u.example.com> |
| In reply to | #129721 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
[...]
> You have to be careful with the consensus.
>
> For example the consensus in this ng will be that Schild's tutorials
> should be avoided. That's because they contain technical errors. But
> that doesn't actually matter too much for a tutorial, people who don't
> have much experience teaching often think that teaching an error is
> a disaster, in fact it's often better to teach a simplification. For
> example void main() is an error in C (C programs must return a
> success / failure flag to the environment, so it should be int main())
> but the vast majority of compilers accept it, and in fact the flag isn't
> really of any use for beginner-level programs.
I strongly disagree with almost everything in that paragraph.
Technical errors in a tutorial do matter. Victims of bad tutorials
can pick up bad habits that last for decades.
Schildt's use of void main() is inexcusable, not just because
it's wrong but because it's a symptom of his technical sloppiness.
He wrote a book "The Annotated ANSI C Standard" consisting of the
1990 ISO C standard with his annotations on facing pages. He used
"void main(void)" as an example right next to the section of the
standard that requires the return type to be int.
In some environments (particularly Unix-like ones), returning a
success/failure indication to the calling environment is *important*.
Using "void main()" or "void main(void)" rather than the correct
"int main(void)" isn't even a significant simplification. And it's
just one of probably hundreds of fundamental errors he made in that
one book.
Incidentally, the C90 standard didn't even have the "or in some
other implementation-defined manner" wording; that was added in C99.
So "void main(void) {}" unconditionally has undefined behavior in C90,
the standard he was discussing.
https://www.davros.org/c/schildt.html
https://www.seebs.net/c/c_tcn4e.html
Teaching a simplified version of something can be useful, but that's
not what Schildt did. He just got things wrong.
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-04-25 18:10 +0100 |
| Subject | Re: [Solved] Need some help getting to my feet |
| Message-ID | <XD2EC.21288$Hc3.7057@fx30.am4> |
| In reply to | #129723 |
On 25/04/2018 17:24, Keith Thompson wrote: > Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > [...] >> You have to be careful with the consensus. >> >> For example the consensus in this ng will be that Schild's tutorials >> should be avoided. That's because they contain technical errors. But >> that doesn't actually matter too much for a tutorial, people who don't >> have much experience teaching often think that teaching an error is >> a disaster, in fact it's often better to teach a simplification. For >> example void main() is an error in C (C programs must return a >> success / failure flag to the environment, so it should be int main()) >> but the vast majority of compilers accept it, and in fact the flag isn't >> really of any use for beginner-level programs. > > I strongly disagree with almost everything in that paragraph. > > Technical errors in a tutorial do matter. Victims of bad tutorials > can pick up bad habits that last for decades. > > Schildt's use of void main() is inexcusable, not just because > it's wrong but because it's a symptom of his technical sloppiness. Rather than blaming Schildt, how about blaming the compilers that allow it? Six of my 7 C compilers will not report that as an error. Some may be persuaded to do so, but that would require expertise beyond what a beginner will have. If compilers routinely rejected such things without having to be told, rather than the other way around, I'd imagine the practice would have died out sooner. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-04-25 10:48 -0700 |
| Subject | Re: [Solved] Need some help getting to my feet |
| Message-ID | <lnwowvgotf.fsf@kst-u.example.com> |
| In reply to | #129728 |
bartc <bc@freeuk.com> writes:
> On 25/04/2018 17:24, Keith Thompson wrote:
[...]
>> Schildt's use of void main() is inexcusable, not just because
>> it's wrong but because it's a symptom of his technical sloppiness.
>
> Rather than blaming Schildt, how about blaming the compilers that allow
> it? Six of my 7 C compilers will not report that as an error. Some may
> be persuaded to do so, but that would require expertise beyond what a
> beginner will have.
I blame both, but the article I responded to was discussing Schildt.
I've said before that I wish compilers (gcc in particular, since
that's the one I use most often) were more strict by default,
warning about obvious undefined behavior (like "void main()")
and rejecting rather than merely warning about constraint violations.
Of course gcc *will* warn about "void main()" if you invoke it with
the right options (and the standard doesn't require a diagnostic
at all). It's unfortunate that novice programmers are required
to perform the extra step of learning the appropriate options.
It's equally unfortunate that some more experienced programmers
refuse to do so.
Schildt was writing a book *about the C standard* and blatantly
misrepresented what it said.
> If compilers routinely rejected such things without having to be told,
> rather than the other way around, I'd imagine the practice would have
> died out sooner.
I agree.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2018-04-25 19:23 +0000 |
| Subject | Casting the return value of malloc() (Was: [Solved] Need some help getting to my feet) |
| Message-ID | <pbqkjk$g4o$1@news.xmission.com> |
| In reply to | #129728 |
In article <XD2EC.21288$Hc3.7057@fx30.am4>, bartc <bc@freeuk.com> wrote: ... >Rather than blaming Schildt, how about blaming the compilers that allow >it? Six of my 7 C compilers will not report that as an error. Some may >be persuaded to do so, but that would require expertise beyond what a >beginner will have. > >If compilers routinely rejected such things without having to be told, >rather than the other way around, I'd imagine the practice would have >died out sooner. I really think we need to get back to talking about (not) casting the return value of malloc(). -- He continues to assert that 2 plus 2 equals 4, despite being repeatedly told otherwise.
[toc] | [prev] | [next] | [standalone]
| From | Bruce S <bruces42@hotmail.com> |
|---|---|
| Date | 2018-04-25 16:55 -0600 |
| Subject | Re: Casting the return value of malloc() (Was: [Solved] Need some help getting to my feet) |
| Message-ID | <pbr105$1kl$1@dont-email.me> |
| In reply to | #129740 |
On 04/25/2018 01:23 PM, Kenny McCormack wrote:
> In article <XD2EC.21288$Hc3.7057@fx30.am4>, bartc <bc@freeuk.com> wrote:
> ...
>> Rather than blaming Schildt, how about blaming the compilers that allow
>> it? Six of my 7 C compilers will not report that as an error. Some may
>> be persuaded to do so, but that would require expertise beyond what a
>> beginner will have.
>>
>> If compilers routinely rejected such things without having to be told,
>> rather than the other way around, I'd imagine the practice would have
>> died out sooner.
>
> I really think we need to get back to talking about (not) casting the
> return value of malloc().
I just tried casting the return of malloc, and it worked fine.
void main() {
char *buffer = (char *)malloc(10);
printf("%s%c", "enter a number", '\n');
gets(buffer);
printf("got %d\n", atoi(buffer));
}
Who could have a problem with that?
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> |
|---|---|
| Date | 2018-04-25 16:03 -0700 |
| Subject | Re: Casting the return value of malloc() (Was: [Solved] Need some help getting to my feet) |
| Message-ID | <pbr1fu$5gq$1@dont-email.me> |
| In reply to | #129754 |
On 4/25/2018 3:55 PM, Bruce S wrote:
> On 04/25/2018 01:23 PM, Kenny McCormack wrote:
>> In article <XD2EC.21288$Hc3.7057@fx30.am4>, bartc <bc@freeuk.com> wrote:
>> ...
>>> Rather than blaming Schildt, how about blaming the compilers that allow
>>> it? Six of my 7 C compilers will not report that as an error. Some may
>>> be persuaded to do so, but that would require expertise beyond what a
>>> beginner will have.
>>>
>>> If compilers routinely rejected such things without having to be told,
>>> rather than the other way around, I'd imagine the practice would have
>>> died out sooner.
>>
>> I really think we need to get back to talking about (not) casting the
>> return value of malloc().
>
> I just tried casting the return of malloc, and it worked fine.
>
> void main() {
> char *buffer = (char *)malloc(10);
> printf("%s%c", "enter a number", '\n');
> gets(buffer);
> printf("got %d\n", atoi(buffer));
> }
>
> Who could have a problem with that?
A person who forgot to include stdlib.h? Btw, are implicit functions
banned from C11? Also, what if you change from char* to another type? It
seems to add more clutter...
Imvho, casting a malloc in C is not Kosher.
[toc] | [prev] | [next] | [standalone]
| From | Bruce S <bruces42@hotmail.com> |
|---|---|
| Date | 2018-04-25 18:02 -0600 |
| Subject | Re: Casting the return value of malloc() (Was: [Solved] Need some help getting to my feet) |
| Message-ID | <pbr4to$p7u$1@dont-email.me> |
| In reply to | #129755 |
On 04/25/2018 05:03 PM, Chris M. Thomasson wrote:
> On 4/25/2018 3:55 PM, Bruce S wrote:
>> On 04/25/2018 01:23 PM, Kenny McCormack wrote:
>>> In article <XD2EC.21288$Hc3.7057@fx30.am4>, bartc <bc@freeuk.com>
>>> wrote:
>>> ...
>>>> Rather than blaming Schildt, how about blaming the compilers that allow
>>>> it? Six of my 7 C compilers will not report that as an error. Some may
>>>> be persuaded to do so, but that would require expertise beyond what a
>>>> beginner will have.
>>>>
>>>> If compilers routinely rejected such things without having to be told,
>>>> rather than the other way around, I'd imagine the practice would have
>>>> died out sooner.
>>>
>>> I really think we need to get back to talking about (not) casting the
>>> return value of malloc().
>>
>> I just tried casting the return of malloc, and it worked fine.
>>
>> void main() {
>> char *buffer = (char *)malloc(10);
>> printf("%s%c", "enter a number", '\n');
>> gets(buffer);
>> printf("got %d\n", atoi(buffer));
>> }
>>
>> Who could have a problem with that?
>
> A person who forgot to include stdlib.h? Btw, are implicit functions
> banned from C11? Also, what if you change from char* to another type? It
> seems to add more clutter...
>
> Imvho, casting a malloc in C is not Kosher.
It was a joke, with more to cause eye tics than the cast.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> |
|---|---|
| Date | 2018-04-25 17:14 -0700 |
| Subject | Re: Casting the return value of malloc() (Was: [Solved] Need some help getting to my feet) |
| Message-ID | <pbr5ka$ssh$1@dont-email.me> |
| In reply to | #129757 |
On 4/25/2018 5:02 PM, Bruce S wrote:
> On 04/25/2018 05:03 PM, Chris M. Thomasson wrote:
>> On 4/25/2018 3:55 PM, Bruce S wrote:
>>> On 04/25/2018 01:23 PM, Kenny McCormack wrote:
>>>> In article <XD2EC.21288$Hc3.7057@fx30.am4>, bartc <bc@freeuk.com>
>>>> wrote:
>>>> ...
>>>>> Rather than blaming Schildt, how about blaming the compilers that
>>>>> allow
>>>>> it? Six of my 7 C compilers will not report that as an error. Some may
>>>>> be persuaded to do so, but that would require expertise beyond what a
>>>>> beginner will have.
>>>>>
>>>>> If compilers routinely rejected such things without having to be told,
>>>>> rather than the other way around, I'd imagine the practice would have
>>>>> died out sooner.
>>>>
>>>> I really think we need to get back to talking about (not) casting the
>>>> return value of malloc().
>>>
>>> I just tried casting the return of malloc, and it worked fine.
>>>
>>> void main() {
>>> char *buffer = (char *)malloc(10);
>>> printf("%s%c", "enter a number", '\n');
>>> gets(buffer);
>>> printf("got %d\n", atoi(buffer));
>>> }
>>>
>>> Who could have a problem with that?
>>
>> A person who forgot to include stdlib.h? Btw, are implicit functions
>> banned from C11? Also, what if you change from char* to another type?
>> It seems to add more clutter...
>>
>> Imvho, casting a malloc in C is not Kosher.
>
> It was a joke, with more to cause eye tics than the cast.
Ack! Sorry for not noticing. ;^o
[toc] | [prev] | [next] | [standalone]
| From | Bruce S <bruces42@hotmail.com> |
|---|---|
| Date | 2018-04-26 13:31 -0600 |
| Subject | Re: Casting the return value of malloc() (Was: [Solved] Need some help getting to my feet) |
| Message-ID | <pbt9f7$r09$2@dont-email.me> |
| In reply to | #129758 |
On 04/25/2018 06:14 PM, Chris M. Thomasson wrote:
> On 4/25/2018 5:02 PM, Bruce S wrote:
>> On 04/25/2018 05:03 PM, Chris M. Thomasson wrote:
>>> On 4/25/2018 3:55 PM, Bruce S wrote:
>>>> On 04/25/2018 01:23 PM, Kenny McCormack wrote:
>>>>> In article <XD2EC.21288$Hc3.7057@fx30.am4>, bartc <bc@freeuk.com>
>>>>> wrote:
>>>>> ...
>>>>>> Rather than blaming Schildt, how about blaming the compilers that
>>>>>> allow
>>>>>> it? Six of my 7 C compilers will not report that as an error. Some
>>>>>> may
>>>>>> be persuaded to do so, but that would require expertise beyond what a
>>>>>> beginner will have.
>>>>>>
>>>>>> If compilers routinely rejected such things without having to be
>>>>>> told,
>>>>>> rather than the other way around, I'd imagine the practice would have
>>>>>> died out sooner.
>>>>>
>>>>> I really think we need to get back to talking about (not) casting the
>>>>> return value of malloc().
>>>>
>>>> I just tried casting the return of malloc, and it worked fine.
>>>>
>>>> void main() {
>>>> char *buffer = (char *)malloc(10);
>>>> printf("%s%c", "enter a number", '\n');
>>>> gets(buffer);
>>>> printf("got %d\n", atoi(buffer));
>>>> }
>>>>
>>>> Who could have a problem with that?
>>>
>>> A person who forgot to include stdlib.h? Btw, are implicit functions
>>> banned from C11? Also, what if you change from char* to another type?
>>> It seems to add more clutter...
>>>
>>> Imvho, casting a malloc in C is not Kosher.
>>
>> It was a joke, with more to cause eye tics than the cast.
>
> Ack! Sorry for not noticing. ;^o
LOL, Poe's Law and all that.
[toc] | [prev] | [next] | [standalone]
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2018-04-26 03:27 +0000 |
| Subject | Re: Casting the return value of malloc() (Was: [Solved] Need some help getting to my feet) |
| Message-ID | <pbrgvf$ln$1@news.xmission.com> |
| In reply to | #129754 |
In article <pbr105$1kl$1@dont-email.me>, Bruce S <bruces42@hotmail.com> wrote:
>On 04/25/2018 01:23 PM, Kenny McCormack wrote:
>> In article <XD2EC.21288$Hc3.7057@fx30.am4>, bartc <bc@freeuk.com> wrote:
>> ...
>>> Rather than blaming Schildt, how about blaming the compilers that allow
>>> it? Six of my 7 C compilers will not report that as an error. Some may
>>> be persuaded to do so, but that would require expertise beyond what a
>>> beginner will have.
>>>
>>> If compilers routinely rejected such things without having to be told,
>>> rather than the other way around, I'd imagine the practice would have
>>> died out sooner.
>>
>> I really think we need to get back to talking about (not) casting the
>> return value of malloc().
>
>I just tried casting the return of malloc, and it worked fine.
>
>void main() {
> char *buffer = (char *)malloc(10);
> printf("%s%c", "enter a number", '\n');
> gets(buffer);
> printf("got %d\n", atoi(buffer));
>}
>
>Who could have a problem with that?
Yes, very well done.
Expect extensive commentary from Kiki (and others) any minute now.
--
The randomly chosen signature file that would have appeared here is more than 4
lines long. As such, it violates one or more Usenet RFCs. In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:
http://user.xmission.com/~gazelle/Sigs/Seriously
[toc] | [prev] | [next] | [standalone]
| From | Dan Purgert <dan@djph.net> |
|---|---|
| Date | 2018-04-26 11:06 +0000 |
| Subject | Re: Casting the return value of malloc() (Was: [Solved] Need some help getting to my feet) |
| Message-ID | <slrnpe3cmf.jmn.dan@xps-linux.djph.net> |
| In reply to | #129754 |
Bruce S wrote:
> On 04/25/2018 01:23 PM, Kenny McCormack wrote:
>> In article <XD2EC.21288$Hc3.7057@fx30.am4>, bartc <bc@freeuk.com> wrote:
>> ...
>>> Rather than blaming Schildt, how about blaming the compilers that allow
>>> it? Six of my 7 C compilers will not report that as an error. Some may
>>> be persuaded to do so, but that would require expertise beyond what a
>>> beginner will have.
>>>
>>> If compilers routinely rejected such things without having to be told,
>>> rather than the other way around, I'd imagine the practice would have
>>> died out sooner.
>>
>> I really think we need to get back to talking about (not) casting the
>> return value of malloc().
>
> I just tried casting the return of malloc, and it worked fine.
>
> void main() {
> char *buffer = (char *)malloc(10);
> printf("%s%c", "enter a number", '\n');
> gets(buffer);
> printf("got %d\n", atoi(buffer));
> }
>
> Who could have a problem with that?
There's something about this that's making that little voice in the back
of my head scream... but I can't quite put my finger on it.
Though, isn't 'main()' supposed to be of type 'int'?
--
|_|O|_| Registered Linux user #585947
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5 4AEE 8E11 DDF3 1279 A281
[toc] | [prev] | [next] | [standalone]
| From | 1alvinalbrecht1@gmail.com |
|---|---|
| Date | 2018-04-25 18:41 -0700 |
| Subject | Re: [Solved] Need some help getting to my feet |
| Message-ID | <0c6e134d-8f31-4ceb-815c-168df4ad65de@googlegroups.com> |
| In reply to | #129723 |
On Wednesday, April 25, 2018 at 10:24:57 AM UTC-6, Keith Thompson wrote: > Schildt's use of void main() is inexcusable, not just because > it's wrong but because it's a symptom of his technical sloppiness. > He wrote a book "The Annotated ANSI C Standard" consisting of the > 1990 ISO C standard with his annotations on facing pages. He used > "void main(void)" as an example right next to the section of the > standard that requires the return type to be int. Just above that the standard will be talking about free-standing implementations where it will state that main is implementation defined. It is quite common to see "void main(void)", "int main(void)" and sometimes other strange forms if the crt is written for a specific application. The requirement that main have form "int main()" or "int main(int argc, char **argv)" is really only speaking to (mainly) unix and windows (the "hosted" environment). These don't make sense in the majority of embedded applications which is one of the main application domains of C. A compiler like gcc has all sorts of targets including embedded ones where the form of main can be different. It could check that main matches those specific forms when compiling for, say, unix (and it will with the right flag) but if it's not going to be a problem then I can see why they don't bother. If you use "int main(void)" all you're saying is you're not accessing argc,argv if provided by the startup code. Using "void main(void)" in an environment like unix that requires a return value is probably an error. However, in an embedded system, declaring "int main(int argc, char **argv)" is most certainly an error when argc,argv don't exist. Returning a value that is never looked at as in "int main(void)" most likely doesn't matter but if the system generates no argc,argv and the return value is never looked at then "void main(void)" is what you want if clarity matters to anyone.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-04-26 07:26 -0700 |
| Subject | Re: [Solved] Need some help getting to my feet |
| Message-ID | <ln1sf2gi1w.fsf@kst-u.example.com> |
| In reply to | #129763 |
1alvinalbrecht1@gmail.com writes:
> On Wednesday, April 25, 2018 at 10:24:57 AM UTC-6, Keith Thompson wrote:
>> Schildt's use of void main() is inexcusable, not just because
>> it's wrong but because it's a symptom of his technical sloppiness.
>> He wrote a book "The Annotated ANSI C Standard" consisting of the
>> 1990 ISO C standard with his annotations on facing pages. He used
>> "void main(void)" as an example right next to the section of the
>> standard that requires the return type to be int.
>
> Just above that the standard will be talking about free-standing
> implementations where it will state that main is implementation
> defined.
You're right, and I probably should have mentioned that.
For hosted implementations (in C90), main *must* be defined with a
return type of int. Defining it with any other return type causes
undefined behavior (which can, of course, appear to "work").
(C99 added permission for other implementation-defined forms.)
For freestanding implementations, the type and name of the program's
entry point are implementation-defined.
That's not what Schildt was talking about, though. He used
"void main(void)" in his commentary on the section of the standard
that specifically talks about hosted implementations.
> It is quite common to see "void main(void)", "int main(void)"
> and sometimes other strange forms if the crt is written for a
> specific application.
> The requirement that main have form "int main()" or "int main(int
> argc, char **argv)" is really only speaking to (mainly) unix and
> windows (the "hosted" environment). These don't make sense in
> the majority of embedded applications which is one of the main
> application domains of C.
It's "(mainly) unix and windows" only because those are the most
common platforms for hosted implementations these days.
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
Page 2 of 7 — ← Prev page 1 [2] 3 4 5 6 7 Next page →
Back to top | Article view | comp.lang.c
csiph-web