Re: getopt.c: optarg should not be initialized

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

On 21.09.2010 18:15, Eric Blake wrote:
> On 09/21/2010 10:11 AM, Christophe Lyon wrote:
> > Well, then, why glibc doesn't initialize optarg?
>
> I don't know.  We are free to copy that if we want, but POSIX does not
> require that we copy that.
>
> > The problem I faced is that, being un-initialized in user code,
>
> Why?  If your user code intends to override the libc getopt, then your
> user code must not use anything uninitialized.  Fix your user code -
> just because it happened to work with glibc does not make it correct.

Sorry, I am not sure to understand your point.
In http://www.opengroup.org/onlinepubs/009695399/functions/getopt.html, 
the only indications about optarg are its declaration as
 extern char *optarg;
and the fact that it gets set by getopt().

Now, in the sample user code I had to deal with, optarg is defined as 
non-uninitialized.

My point is that a link time, the linker complains about multiple 
definitions of getopt, and no error message mentions optarg.

I think it's hard for the user to infer that initializing optarg will 
fix his problem, especially given the fact that most users don't know 
they are using newlib and are going to give a look at its sources to 
understand the source of the problem.

I just meant that removing the useless initialization of optarg would 
avoid such error messages which are not obvious to fix. (useless because 
optarg is defined by getopt()).

Christophe.