Re: tlug: gcc question

[Fredric Fredricson <fredric.fredriksson@example.com>]

Selva Nair wrote:
> 
> On Thu, 13 Jan 2000, Fredric Fredricson wrote:
> 
> >    You are right that gcc/egcs, or any c compiler for that matter, does not
> >    initialize the pointers but Linux will clear all new pages so in this
> >    particular case both pointers will be "initialized" to 0.
> >    It is of course a bug to rely on this but I have seem dozens of
> >    programs that does (probably/hopefully unintentional).
> >
> >    From a developers point of view it is a good thing that Linux
> >    does not allow access to memory address 0. This way uninitialized
> 
> Really? I have never seen that happening though. In my
> experience, uninitialized pointers on egcs/Linux do point to arbitrary
> locations..
> 
> Try this:
> 
> int main()
> {
>   char *c1, *c2, *c3;
> 
>   printf("%d %d %d\n", c1, c2, c3);
> 
>   return 0;
> }
> 
> Selva
> 
Hmmmm.... it seems like my Linux 2.0/gcc 2.7/libc5 combination
differs from my Linux 2.2/egcs 2.91/glibc .
In 2.0/2.7/libc5 I always get the pointers in the example set to
zero but in 2.2/2.91/glibc they get "arbitrary" values (always
the same "arbitrary" values).

But consider:

char *c0 ; // variable in the data segment (or whatever it is called
           // in Linux)
int main()
{
   char *c1, *c2, *c3;  // on the stack (automatic)
   char **c4 ;
   c4 = (char**) malloc(sizeof(char*)) ; // pointer on the heap
 
   printf("%d %d %d %d %d\n", c0, c1, c2, c3, *c4);
 
   return 0;
}

Using egcs/libc6 here c0 gets initiated to 0 and *c4 will 
also be 0. c1,c2,and c3 are set to "arbitraty" values. c1, c2 and
c3 are all located on the stack so I suspect that
the stack area get clobbered by some initialization routine
(one of those mysterious __libc_start_main, _init and _start).

So obviously it is not always true that the first variables
pointers get initiated to zero. 
Nor is it true that you can trust the simplest c program
unless you initialize your variables properly, but this is
hardly news.....

/Fredric

PS I tried to confirm the stack-area-gets-clobberer theory 
   by looking at the stack contents but I failed and it's 
   getting late and I need some sleep so I give up and leave
   the explanation to somebody else.
-------------------------------------------------------------------
Next Technical Meeting: January 14 (Fri) 19:00
* Topic: "glibc - current status and future developments"
* Guest Speaker: Ulrich Drepper (Cygnus Solutions)
* Place: Oracle Japan HQ 12F Seminar Room (New Otani Garden Court)
-------------------------------------------------------------------
more info: http://www.tlug.gr.jp        Sponsor: Global Online Japan