Re: long options again

[Brandon Carpenter <hashstat () pnnl gov>]

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 () kaiser cx <mailto:lists () kaiser cx>>
>
>     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... () bredband net <mailto:a.bro... () bredband net>> 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.


___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe