RE: getopt.c: optarg should not be initialized

["Schwarz, Konrad" <konrad dot schwarz at siemens dot com>]

Christophe,

could you explain your problem in more detail,
with an example, perhaps?

Konrad

> -----Original Message-----
> From: newlib-owner@sourceware.org 
> [mailto:newlib-owner@sourceware.org] On Behalf Of Christophe Lyon
> Sent: Wednesday, September 22, 2010 1:27 PM
> To: Eric Blake
> Cc: newlib@sourceware.org
> Subject: Re: getopt.c: optarg should not be initialized
> 
> 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.
> 
>