[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Derek Price
Subject: Re: [bug-gnulib] Re: getopt and Solaris 10
Date: Mon, 09 May 2005 13:22:14 -0400
User-agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)

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.



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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]