Wed Nov 30 20:08:00 GMT 2005
Shaun Jackman wrote:
>2005/11/30, Gregory Pietsch <email@example.com>:
>>The reason why I called it GETOPT_LONG_OPTION_T is because I thought
>>"option" was too generic by itself.
>>I didn't put const in there because it's easier on me. If I want it to
>>be a constant, I just don't modify it. ;-)
>It must be 'struct option' to be source compatible with GNU glibc. It
>must be const to be source compatible with both SUSv3 and GNU glibc.
>Modifying either of these would cause a lot more trouble than it's
>worth. The const modifier requires a disclaimer, because if
>permutation is allowed, it's not really const.
I didn't know GNU glibc compatability was a requirement; SUSv3
compatability should probably be, though, where it does not contradict
the C99 standard. (There are many places in the SUSv3 standard that
contradict itself or are otherwise inadequate such as how a locale
determines the mapping between multibyte and wide-character strings.
It's probably best to err on the side of allowing the most latitude in
the structure of how options are seen without going too overboard.)
I one used a compiler, where, to save compilation time, the const and
volatile qualifiers were no-ops. The optstring parameter should be
const, as I'm not modifying that, but declaring the argv-parameter as
char * const argv is weird.
According to Section 220.127.116.11.1 of the C99 standard (paragraph 2,
sub-paragraph 5), and the same place in the C89 standard, the parameters
to main() are modifiable. Permuting is what the glibc getopt does; at
least I'm not losing information. Does the C99 standard trump SUSv3 over
here? Am I grasping at straws, or is my argument sane?
More information about the Newlib