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 Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs _______________________________________________ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
