This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

getopt() musings

First off, let me state the facts as I understand them:

Cygwin's libc provides an implementation of getopt() and getopt_long().

The implementation provided in Cygwin is derived from the NetBSD implementation of getopt_long() witch was in turn designed to be reasonably compatible with GNU getopt_long().

Cygwin does not use the (traditional) getopt() implementation provided with newlib.

getopt() is a POSIX standard.

getopt_long() is a GNU extension.

Both the GNU and NetBSD implementations of getopt_long() also provide a version of getopt() with additional features that are not a part of (and incompatible with) POSIX getopt(). One additional feature of particular interest is argument permutation. The POSIX definition of getopt() specifies that all options must appear before any non-option arguments and so any option-like argument (one that starts with '-') appearing after a non-option argument will not be treated as an option. With argument permutation, on the other hand, getopt() dynamically reorders the elements of the argv array so as to place all options before any non-options. This behavior is incompatible with the POSIX definition of getopt() and no doubt breaks some programs that rely on the traditional/standard behavior. For this reason the extend versions of getopt() provide ways to disable argument permutation. One way is by setting the environment variable POSIXLY_CORRECT, another is by passing a special character at the beginning of the (short) option string.

Cygwin's implementation of getopt() and getopt_long() were modified to leave argument permutation disabled by default and only enabled when the environment variable POSIXLY_INCORRECT_GETOPT is defined.

Ok, those are the facts as I understand them, if I am wrong about anything I trust that I will be corrected with expeditious and forthright meanness. :)

Additionally, I make the following suppositions:

Argument permutation is desierable. Except, of course, when it breaks something.

It would be overly burdensome to explicitly enable/disable getopt() features on a case-by-case basis for getopt() using packages that are part of the Cygwin distribution.

And now for some discussion:

I am not familiar with all the details of the evolution of getopt_long(), but I assume that argument permutation was present and enabled by default fairly early. I therefore assume that programs using getopt_long() are either compatible with argument permutatuin or have explicitly disabled it.

So here's the idea: Leave argument permutation disabled by default for getopt() and enabled by default for getopt_long().

This is a win if only because many if not most GNU programs use getopt_long(), especially those in the coreutils package.

This would allow us the convenience of argument permutation for many programs while also maintaining standards compliance and compatibility. Right?

So it could work like this:

getopt() would have argument permutation disabled by default and only enabled when POSIXLY_INCORRECT_GETOPT is defined and it is not explicitly disabled by the calling code.

getopt_long() would have argument permutation enabled by default and disabled when POSIXLY_CORRECT is defined or it is explicitly disabled by the calling code.

Does any of this make sense?

(Note that I'm not asking anyone to implement this and I am familiar with the concept of "PTC". For now, I would just like to know what others think.)


From the hottest toys to tips on keeping fit this winter, you?ll find a
range of helpful holiday info here.

-- Unsubscribe info: Problem reports: Documentation: FAQ:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]