#1555 libmingwex.a: getopt_long_only() mishandles short options

closed-fixed
2012-08-03
2011-06-01
No

Assigning to Chris for info; I've already applied the attached patch to fix.

While developing the options handling protocol for mingw-get, I encountered a problem in our getopt_long_only() implementation; the attached Q&D test case illustrates it. In summary: the -verbose option allows assignment of a verbosity level (limited to 0..3 in mingw-get, but unrestricted in the test case; this maps to a short -v form, which increments it by one, from zero initially, for each repetition of -v; (thus -vv should raise it to two).

With the current implementation, (running in wine) I see:

$ ./getopt-test.exe -v
Z:\home\keith\getopt-test.exe: option `-v' is ambiguous

where I should have seen:

$ ./getopt-test.exe -v
Increment verbosity to 1

However:

$ ./getopt-test.exe -vv
Increment verbosity to 1
Increment verbosity to 2

does behave as expected.

Interestingly, the self same test case, when compiled natively on this LinuxMint-10 box, exhibits a complementary defect in the GNU glibc implementation of getopt_long_only():

$ ./getopt-test -v
Increment verbosity to 1

exhibits correct behaviour, but:

$ ./getopt-test -vv
Increment verbosity to 1
./getopt-test: option `-vv' is ambiguous

is incorrect. Additionally:

$ ./getopt-test -vvv
Increment verbosity to 1
Increment verbosity to 2
./getopt-test: option `-vv' is ambiguous

suggests that all but the last in a repeated run are handled correctly, while the last then needs disambiguation:

$ ./getopt-test -vvverb
Increment verbosity to 1
Increment verbosity to 2
Increment verbosity to 3

works, (although it seems wrong that it should; IMO the option should either be a pure long form option, or exclusively short form, and I would consider this strange hybrid case to represent a bug).

With the current libmingwex.a implementation, this hybrid case exhibits this behaviour:

$ ./getopt-test.exe -vvverb
Increment verbosity to 1
Increment verbosity to 2
Increment verbosity to 3
Z:\home\keith\getopt-test.exe: unrecognised option `-erb'

With the patch applied, the new MinGW implementation exhibits correct behaviour in all of the above cases, including rejection of the anomalous hybrid case, (as it should, IMO):

$ ./getopt-test.exe -vvverb
Z:\home\keith\getopt_test.exe: unrecognised option `-vvverb'

As noted above, I've already applied this patch in our CVS. I'm also shipping, (and requiring), this modified implementation with mingw-get, so that it will function correctly, even if built against a buggy old libmingwex.a or glibc.

Discussion

  • Keith Marshall

    Keith Marshall - 2011-06-01

    source for test case

     
  • Keith Marshall

    Keith Marshall - 2011-06-01
    • milestone: --> IINR_-_Include_In_Next_Release
    • status: open --> open-fixed
     
  • Earnie Boyd

    Earnie Boyd - 2012-08-03

    Any reason to leave this open? If so the please reopen it.

     
  • Earnie Boyd

    Earnie Boyd - 2012-08-03
    • status: open-fixed --> closed-fixed
     
  • Keith Marshall

    Keith Marshall - 2012-08-03

    > Any reason to leave this open?

    From my perspective, none at all. I opened it for info, (and to record the issue), fully expecting Chris to close it straight away.

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks