Hi Edward,

I was more worried about the effect that it would have on the 2nd tier platforms, some of which don't have getopt_long_only - which I think is desirable due to the two-character short options that need to be dealt with. 

My feeling is that writing and maintaining a correct getopt_long_only as a fallback for those platforms - which I assume someone would have to do - might take more effort than putting togther something less general / more tailored to how the RTS parses the options.

I've been idly thinking about how to approach this problem enough that I think I'm going to put some proof-of-concept code together just to test the ideas / so my metaphorical teeth stop itching.

At the core of the idea is the options would be stored in an array of structs of the form
  {option-string, has_argument, is_safe, function_pointer_to_handler}
where the function pointer is probably of the form
  int(RtsFlags*, some-error-info-struct*)
or possibly
  int(RtsFlags*, some-cross-option-information-sharing-struct*, some-error-info-struct*)

I've been in the C++ world for a while now, so I'll need to double check the standard / idiomatic way to express that in C. 

If options don't effect anything but the flags or the error state, it seems to me that the overall complexity of the option parsing code would drop.  I don't know what the priority of option parsing performance is, but there are quite a few optimisations available that wouldn't complicate the code all that much.

If anyone has any thoughts on this, I'd love to hear them before I get too far along.

Cheers,

Dave