Re: getopt.c: optarg should not be initialized

[Christophe Lyon <christophe dot lyon at st dot com>]

On 21.09.2010 18:02, Eric Blake wrote:
> On 09/21/2010 09:53 AM, Christophe Lyon wrote:
> > Hello,
> >
> > I think that in newlib/libc/stdlib/getopt.c, optarg should not be
> > initialized (like in glibc).
> >
> > Otherwise, if the user code contains a non-initialized "optarg" variable
> > the linker will "magically" pull the whole getopt.o from Newlib, which
> > is not desirable (especially if the user code actually contains a
> > redefinition of getopt&  co, as it will result in "multiply defined"
> > errors).
>
> I disagree.  If an implementation is going to provide an alternate
> getopt implementation, it must provide the entire implementation.  That
> is, if you are intending to use an alternate getopt implementation, then
> your alternate should also initialize optarg rather than leaving it
> uninitialized, so that the linker finds all of the getopt-related
> symbols in your replacement .o without having to resort to the newlib
> library in the first place.  Remember, overriding library symbols puts
> you in uncertain territory in the first place, so it is your code that
> is suspect rather than the library, and the library shouldn't have to be
> changed to accommodate suspect code.


Well, then, why glibc doesn't initialize optarg?

The problem I faced is that, being un-initialized in user code, optarg 
is put in the COMMON section; if libc was not linked in, it would be 
fine (the 'common' optarg would end up in bss), but the libc optarg is 
being pulled by the linker because it's optarg is initialized.

Christophe.