Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: Re: [Wireshark-dev] long options again

From: Brandon Carpenter <hashstat@xxxxxxxx>
Date: Tue, 16 Jul 2013 08:38:09 -0700
I have to say that I dislike getopt() and getopt_long() for option parsing because of the disconnect between the options and the help.  It creates multiple places that require updating when options change and quite often, one of those places is forgotten.  So on Linux I prefer a parser like argp (in libc).  And it looks like goption, though perhaps a bit more complex, is similar.  While it may be a bit of work up front to change to goption, it will likely make option additions/changes easier in the future.

My two cents... for what it's worth. ;-)

Brandon

On 07/16/2013 02:22 AM, Pascal Quantin wrote:
2013/7/15 Martin Kaiser <lists@xxxxxxxxx>
Hi,

this was discussed months ago, I also raised this briefly at Sharkfest -
but I changed my mind since then.

>> Guy Harris skrev 2013-04-09 00:32:

>>> On Apr 8, 2013, at 3:02 PM, Anders Broman <a.bro...@xxxxxxxxxxxx> wrote:

>>> I think we have getopt_long already
>>> http://anonsvn.wireshark.org/viewvc?view=revision&revision=41926

>> We do, so we have it available on both platforms that have it (most
>> UN*Xes, these days) and platforms that don't (Windows, which has neither
>> getopt() nor getopt_long(), and perhaps some current UN*Xes and older
>> versions of other UN*Xes).

We don't have getopt_long() on windows at the moment. But we're
99% there. All it takes is copying another 10 lines from glibc.

It looks like getopt() and getopt_long() share a lot of helper
functions. So we're not pulling in a lot of new code if we provide a
getopt_long() implementation on windows.

>>We're not using it, however; did you check that in for future use, and
>>did you have any future use in mind?

>I think it was added in conjunction with looking at
>https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2473 at the time I
>think there were discussion about using long options for various stuff.
>I just added it so we would have all options open as I didn't quite like
>the glib implementation for some reason I don't quite remember now.

Lately, I played a bit more with the goptions. Changing completely from
getopt() to goptions seems a lot of work for no real benefit (unless we
do this everywhere where getopt() is used at the moment).

I tried to use goptions only for the long opts and leave getopt() in
place for the existing options. They don't co-exist well, there's always
a way to produce strange errors.

In short: Contrary to what I said at sharkfest, I believe that
getopt_long() is the way to go. Unless anyone protests, I'll make the
required changes and start using it.

Best regards,

   Martin

Hi Martin,

on my side I definitely see the use for long options: we are starting to run out of letters and you already have inconsistencies between various applications.
The use of getopt_long() seems a good tradeoff.

Best regards,
Pascal.