getopt_long(3): note an inconsistency with getopt(3) in BUGS

getopt_long(3) will not allow an `optind` setting of 0 to be bug-for-bug
compatible with the GNU implementation, as some software does rely on
it.  Document it as a BUG, since it affects previous declarations of
compatibility with getopt(3).

Reviewed by:	pauamma (markup)
Sponsored by:	Klara, Inc.
Differential Revision:	https://reviews.freebsd.org/D37867
This commit is contained in:
Kyle Evans 2023-02-10 23:31:13 -06:00
parent 3e230e0cc4
commit d646513e57

View file

@ -31,7 +31,7 @@
.\" @(#)getopt.3 8.5 (Berkeley) 4/27/95
.\" $FreeBSD$
.\"
.Dd May 2, 2018
.Dd December 24, 2022
.Dt GETOPT_LONG 3
.Os
.Sh NAME
@ -546,3 +546,19 @@ is set).
The implementation can completely replace
.Xr getopt 3 ,
but right now we are using separate code.
.Pp
.Nm
makes the assumption that the first argument should always be skipped because
it's typically the program name.
As a result, setting
.Va optind
to 0 will indicate that
.Nm
should reset, and
.Va optind
will be set to 1 in the process.
This behavior differs from
.Xr getopt 3 ,
which will handle an
.Va optind
value of 0 as expected and process the first element.