getopt.c: optarg should not be initialized

[Eric Blake]

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.

>
> Small patch as follows:
>
> Index: newlib/libc/stdlib/getopt.c
> ===================================================================
> --- newlib/libc/stdlib/getopt.c (revision 637)
> +++ newlib/libc/stdlib/getopt.c (working copy)
> @@ -103,7 +103,7 @@ typedef enum GETOPT_ORDERING_T
> } GETOPT_ORDERING_T;
>
> /* globally-defined variables */
> -char *optarg = 0;
> +char *optarg;
> int optind = 0;

On the other hand, this is a real bug.  POSIX requires that optind be 
initialized to 1.

-- 
Eric Blake   eblake@redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org