Bug#192834: Glibc's method of resetting getopt different, causes interoperability problems

[GOTO Masanori <gotom@debian.or.jp>]

Hi,

At Fri, 8 Oct 2004 11:18:17 -0400,
Theodore Ts'o wrote:
> Unfortunately, gnu glibc has extra allocated memory which is used to
> support long options (i.e., --help).  This information is only reset
> when you set optind=0 before calling getopt() to parse a new set of
> argv[] vectors.  If you do not reset optind to 0 before parsing a new
> set of argv[] vectors, getopt will core dump.  Unfortunately, on BSD
> systems, you have to set optind=1 before parsing a new set of argv[]
> vectors, or BSD systems will core dump.

I don't find where extra allocated memory operation is used; where
could you tell me such code?

> To reproduce, recompile e2fsprogs and remove the magic GLIBC branch
> below, and if you always reinitialize optind=1 in reset_getopt(), you
> will watch getopt core dump rather spectacularly after executing a
> number of debugfs commands with and without options.

I tried, but I could not reappear core dump.  If you know or don't
know such sequence, please let me know.  I guess if we change optind
to wrong position, internal state of _getopt_data is corrupted.

BTW, this getopt is derived from gnulib, and it seems we can easily
support getopt = 1 condition.  My test patch is attached, and I'm
looking through the code.  I'll try to contact author.  optreset is
BSD magic, and I guess we do not need to support them.

--- posix/getopt.c      10 Mar 2004 23:13:26 -0000      1.53
+++ posix/getopt.c      10 Oct 2004 23:35:12 -0000
@@ -403,7 +403,7 @@
 
   d->optarg = NULL;
 
-  if (d->optind == 0 || !d->__initialized)
+  if (d->optind == 0 || d->optind == 1 || !d->__initialized)
     {
       if (d->optind == 0)
        d->optind = 1;  /* Don't scan ARGV[0], the program name.  */

Regards,
-- gotom