[sf-lug] K & R errata ; addendum re null.c

[jim]

re C code for null.c 

$ file null   # to show null is a valid ELF file 
null: ELF 32-bit LSB executable... 
$ ls -l null 
-rwxr-xr-x 1 jim jim 7102 2011-07-05 11:55 null
$   # a program with a main with an empty statement is 7K 
$ valgrind -v ./null   # valgrind wants a path 
...
==12133== HEAP SUMMARY:
==12133==     in use at exit: 0 bytes in 0 blocks
==12133==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==12133== 
==12133== All heap blocks were freed -- no leaks are possible
==12133== 
==12133== For counts of detected and suppressed errors, rerun with: -v
==12133== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 12 from
7)




On Tue, 2011-07-05 at 12:05 -0700, jim wrote:
> 
>     Thanks for terrific additions: 
> 
> int a = (int *) malloc(100*sizeof(int)); 
> // nice example of use of sizeof 
> 
> 
> "They should both get initialized to zero, which means that they should
> go into the .bss section of the ELF file...." 
> JS: This is Linux-specific behavior? I.e. not necessarily true 
> for non-Linux OSes? Or maybe forced or optionally forced by 
> the gcc compiler? 
> 
> 
> "readelf is a command that comes with binutils and allows examination of
> precisely what is inside executables." 
> JS: 
> $ which readelf 
> /usr/bin/readelf  # probably comes with default Ubuntu 10.04 (my OS) 
> $ vi null.c  # int main() { ; } 
> $ gcc -o null null.c 
> $ ./null 
> $ readelf -a null 
> ... <wow!> ... 
> 
> 
> "Hallinan's _Embedded Linux Primer_ (far and away my favorite book) has
> helpful comments...."
> JS: PDF is available from http://scorpius.homelinux.org (4.4MB) 
> hardcopy book is distributed by Prentice Hall 
> 
> 
> "valgrind --tool=memcheck" is the other gold-standard Linux memory
> checker, as is well-known. 
> JS: 
> # apt-get install valgrind  # 16+ MB download 
> http://manpages.ubuntu.com/manpages/gutsy/man1/valgrind.1.html 
> (a highly streamlined tutorial is at: ) 
> http://www.pcdebug.com/linux-debugging/a-primer-on-valgrind-valgrind-tutorial.html
> 
> 
> "BTW Jim, I don't mean to be a flamer, but capitalization does help with
> legibility." 
> JS: no offense taken, thanks for the criticism. I use no-caps 
> for convenience in conversational missives. My take-away is 
> to stop doing so for other than brief comments. Readability 
> is big with me. 
> 
> 
> 
> On Tue, 2011-07-05 at 00:38 -0700, Alison Chaiken wrote:
> > Thanks to everyone for a fascinating discussion.     I note that
> > there's an Erlang tutorial during OSCON:
> > 
> > http://www.oscon.com/oscon2011/public/schedule/detail/19085
> > 
> > I'm already signed up.
> > 
> > jim <jim at systemateka.com> writes:
> >         I think declaring a variable is
> >         type identifier, e.g.
> >         int i;
> >         and defining a variable is
> >         type identifier assign value, e.g.
> >         int j = 3;
> >         
> >           the compiler may set up images of segments for
> >         machine code (the text segment), data, and the stack(s)
> >         during its compile phase or defer that work until it's
> >         in the optimizing phase.
> >            regardless, it may "allocate" memory for a declared
> >         variable or not, depending on the variable's status as
> >         global or as local within some function. 
> >         Regarding whether storage is allocated for declared variables
> >         
> > I've noticed that declaring
> > 
> > 
> >         int a[100];
> > 
> > 
> > increases the size of a binary while
> > 
> > 
> >         int a = (int *) malloc(100*sizeof(int));
> > 
> > 
> > does not.        That's what you'd expect, as one set of numbers is
> > statically allocated, while the other is allocated dynamically.   They
> > should both get initialized to zero, which means that they should go
> > into the .bss section of the ELF file (the executable) that the linker
> > produces at the end of compilation.
> > 
> > 
> >            the language designers themselves were careful to
> >         keep I/O and platform and compiler designs out of the
> >         specification. 
> >         
> >         
> > True dat, but if I understand correctly, the ELF format used by Linux
> > executables (not just C ones) does constrain the allocations.
> >  readelf is a command that comes with binutils and allows examination
> > of precisely what is inside executables.    Hallinan's _Embedded Linux
> > Primer_ (far and away my favorite book) has helpful comments about
> > using binutils to answer questions like this in Chapter 13.   The
> > Hallinan book is available as a free download, but you should buy a
> > hardcopy so that you can sleep with it under your pillow.
> > 
> > 
> > "valgrind --tool=memcheck" is the other gold-standard Linux memory
> > checker, as is well-known.
> > 
> > 
> > BTW Jim, I don't mean to be a flamer, but capitalization does help
> > with legibility.
> > 
> > -- 
> > Alison Chaiken
> > (650) 279-5600  (cell)
> > http://www.exerciseforthereader.org/
> > Spend much time at the cutting edge and you're liable to get cut.
> > 
> > _______________________________________________
> > sf-lug mailing list
> > sf-lug at linuxmafia.com
> > http://linuxmafia.com/mailman/listinfo/sf-lug
> > Information about SF-LUG is at http://www.sf-lug.org/
> 
> 
> 
> _______________________________________________
> sf-lug mailing list
> sf-lug at linuxmafia.com
> http://linuxmafia.com/mailman/listinfo/sf-lug
> Information about SF-LUG is at http://www.sf-lug.org/