Re: [parisc-linux] new glibc dpatch

["Carlos O'Donell Jr." <carlos@megatonmonkey.net>]

> > 
> > =====
> > --- glibc22-hppa.dpatch	Tue Oct 16 20:52:02 2001
> > +++ glibc22-hppa.dpatch.mw	Tue Oct 16 21:05:27 2001
> > @@ -1135,7 +1135,7 @@
> >       unsigned int npages;		/* # of pages to allocate */
> >   #ifdef _LIBC_REENTRANT
> >  -    volatile int lock;
> > -+    __atomic_lock_t lock;
> > ++    static __atomic_lock_t lock = __ATOMIC_LOCK_INIT;
> >       sigset_t full_sigset;
> >   #endif
> >       /* the next to members MUST be consecutive! */
> > =====
> 
> I'm not sure what meaning static would have in this context.  It doesn't
> have to be initialised because every arch other than PA defines an
> unlocked lock to be 0.  If it gets initialised, it gets put in .data
> (instead of .bss), even if you're initialising it to 0.  Stupid, I know.
>

My bad. The entire struct is defined as static.
The static identifier was to prevent external modifcation of the value.
However since it's encased in a "static struct local" it's not an issue.

True. Any initialized value needs to be shipped into .data, and we
begin to see some ugly .data bloat (even if the user is just specifying
zero anyway...)


I think I'm going to get some sleep now ... to many "my bad" in one 
day ^__^;;;

c.