Re: lib/59828: getopt(3) GNU extension wrong behavior

["Simon Wollwage via gnats" <gnats-admin%NetBSD.org@localhost>]

The following reply was made to PR lib/59828; it has been noted by GNATS.

From: Simon Wollwage <rootnode%wollwage.com@localhost>
To: "Michael van Elst via gnats" <gnats-admin%NetBSD.org@localhost>
Cc: lib-bug-people%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost,
 rootnode+netbsd%wollwage.com@localhost,  gnats-bugs%netbsd.org@localhost
Subject: Re: lib/59828: getopt(3) GNU extension wrong behavior
Date: Wed, 10 Dec 2025 22:57:54 +0900

 "Michael van Elst via gnats" <gnats-admin%NetBSD.org@localhost> writes:
 
 >  NetBSD date doesn't have an -I option.
 >  
 >  The coreutils package from pkgsrc contains a date command, but
 >  which works the same as on Linux:
 >  
 >  NetBSD-10, coreutils-9.6nb1:
 >  
 >  % /usr/pkg/gnu/bin/date -I date
 >  date: invalid date date
 
 Sorry, copied that stupidly forgetting that the date tool might be
 different. First contribution, so I didn't have that on my radar.
 
 >  I don't think your interpretation of the manual page is correct,
 >  but without an example for "x::" maybe misleading.
 
 >From a quick perusal it seems that sed ant syslogd for example are using
 it.  On the ports side it might be more.
 
 >  "If an individual character is followed by two colons, then the
 >  option argument is optional; optarg is set to the rest of the
 >  current argv word, or NULL if there were no more characters in the
 >  current word."
 >  
 >  So, the option argument is "the rest of the current argv word" or "NULL".
 >  It is never "the following word if that doesn't start with a dash".
 
 The paragraph ends with
 
 "It does not matter to getopt() if a following argument has leading
 whitespace."
 
 I guess that is the part I am unsure about and interpretet as also
 counting for the double colon case.
 
 >  No idea why FreeBSD calls it a "GNU extension" while NetBSD calls it
 >  a "NetBSD extension" or who actually created it...
 
 In the source code to getopt it is calledt a GNU extension.
 
 If the consensus is that the wording about the whitespace doesn't apply
 to the double colon case, then happy to drop it.  From a consistency or
 UX viewpoint I would say it makes sense to allow the whitespace for
 both, single and double colon.