Re: [bug-gnulib] Re: getopt and Solaris 10

[Derek Price]

Regardless, since using an optind = 0 is not specified as supported by
POSIX, whereas optind = 1 is, and since using optind = 1 in place of
optind = 0 in CVS would avoid this problem on all platforms and with all
versions of getopt (supporting optind = 0 provides no additional
functionality that I know of), I don't think this is properly considered
a Solaris bug, but a CVS bug.

At least, it would be a CVS bug if we didn't have to use the GNU getopt
on Solaris due to the "+" problem anyhow.

Cheers,

Derek


Derek Price wrote:

> Matthias Kurz wrote:
>
> >Hi.
>
> >One more clarification. Maybe one or the other missed my last comments
> >on <https://ccvs.cvshome.org/issues/show_bug.cgi?id=248>. It was me,
> >who introduced the "'+' myth".
>
>
>
> Well, it is not a myth.  I studied the test program and output you sent
> me, and Solaris does, indeed, treat the initial "+" as an option rather
> than a request for getopt() semantics.
>
> >I "analysed" the problem wrong in the
> >beginning. It is not exactly the "+" that makes the problem, but the
> >fact, that the Solaris getopt refuses to accept a zero value on optind.
> >When "optind==0", the Solaris getopt returns -1 immediately, leaving
> >optind==0. W
>
>
>
> I did read this correctly in your report.  If anyone else sees a need
> for an actual test for correct optind=0 behavior, then they are welcome
> to write one, but I decided the point was moot at the moment since
> detecting the "+" bug, just as valid as a means of selecting the GNU
> getopt() over the system one, was sufficient to avoid encountering any
> other bugs in the Solaris getopt().
>
> Cheers,
>
> Derek


_______________________________________________
Bug-cvs mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/bug-cvs