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

["Robert Elz via gnats" <gnats-admin%NetBSD.org@localhost>]

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

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: lib/59828: getopt(3) GNU extension wrong behavior
Date: Thu, 11 Dec 2025 17:37:40 +0700

     Date:        Wed, 10 Dec 2025 18:05:01 +0000 (UTC)
     From:        "Simon Wollwage via gnats" <gnats-admin%NetBSD.org@localhost>
     Message-ID:  <20251210180501.BE59C1A923A%mollari.NetBSD.org@localhost>
 
   |  That is less confusing (even if I think that UX might be better if the
   |  whitespace were allowed, but that is besides the point.
 
 It is impossible, think of what happens if either:
 
 1) you want the optarg to -d to be -14 instead of 14, what would your
    proposed patch to with cmd -d -14 ... ?
 
 2) there are no more options after the -d (whose optional value is not
    wanted) and the next arg is a filename (or something - a positional arg).
     Is the plan to always require using the -- arg?   Or given 1 above
    would that -- just be treated as the optarg to -d  (cmd -d -- whatever)
 
 With single : options, where the optarg is required, it doesn't matter,
 if the optarg value doesn't immediately follow the option character
 (without intervening anything) then the next arg is the optarg value,
 whatever it looks like (if there is none it is an error).
 
 But with optional optargs (::) there needs to be a clear, obvious, way
 to determine if the optional optarg is there or not).  And it has to work
 in every conceivable case.
 
 kre