getopt_long

[Gregory Pietsch]

Shaun Jackman wrote:

>2005/11/30, Gregory Pietsch <gpietsch@comcast.net>:
>  
>
>>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. ;-)
>>
>>Gregory Pietsch
>>    
>>
>
>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.
>
>Cheers,
>Shaun
>
>  
>
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 5.1.2.2.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?

Gregory Pietsch