[sf-lug] K & R errata

[jim]

    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/