Verification of this bug is really simple in the popt compilation directory: $ ./test1 --optional --optional arg1: 0 arg2: (none) oStr: --optional Obviously, oStr _must_ be "(none)" here as there are not values given to the --optional parameter, just like $ ./test1 --optional arg1: 0 arg2: (none) oStr: (none) I guess, popt doesn't check if the next argument is an option (e.g. beginning with - or -- but not being "-"). This would mean that parameter with an optional argument can only appear at the end and no two of them can be used at the same time. It's very obvious that this cannot be the wanted behaviour. Also getopt_long does this correctly Was this bug always there or introduced lately? If there is a working version, how can I check it's version from e.g. an autoconf script to be able to tell a user to not use a bad version? My current version of popt is the version in Debian Sarge, namely: ii libpopt0 1.7-2 lib for parsing cmdline parameters Thanks for your support Hendrik Sattler
This problem is fixed in (at least) popt-4.4.6 and later: $ ./test1 --optional --optional arg1: 0 arg2: (none) oStr: (none)