On 7/7/20 5:34 AM, Marc Nieper-Wißkirchen wrote:
> Whatever SRFI 37 does, for the user it should be compatible with GNU's
> getopt_long, which means that optional arguments to long options have
> to use the '=' syntax.

I very much agree about this. It does conflict with the SRFI-37 sample
implementation, as I point out in my other note.

> And optional arguments to short options have to
> be in the same argv element according to the documentation to GNU's
> getopt.

This seems very strange to me. It violates the document I referenced for
GNU guidelines in the SRFI:

https://web.archive.org/web/20030805192036/https://www.gnu.org/manual/glibc/html_node/Argument-Syntax.html

"An option and its argument may or may not appear as separate tokens.
(In other words, the whitespace separating them is optional.) Thus, -o
foo and -ofoo are equivalent."

However, you are correct that this is the current documented behavior
for GNU getopt_long documented behavior:

"If such a character is followed by a colon, the option requires an
argument, so getopt() places a pointer to the following text in the same
argv-element, or the text of the following argv-element, in optarg. Two
colons mean an option takes an optional arg; if there is text in the
current argv-element (i.e., in the same word as the option name itself,
for example, "-oarg"), then it is returned in optarg, otherwise optarg
is set to zero."

I wonder is this is a limitation of the GNU implementation which
actually violates their recommendations?

I'm not sure it would be a good idea to change SRFI-37 itself, because
it could break code, but you could create a revision with a new SRFI
number to address the long argument issue.

--
Anthony Carrico