If you use the short version "-r" for a reference file, the value of longindex is not trustable (as per all getopt_long calls), and so sometimes the warning triggers, and sometimes it doesn't. Minimal testcase attached. Notice that long_index is not trustable with short option -r, and in the original src/touch.c, this can spuriously give the --file obsolete warning. Test output: ====== CMD ./getopt_long_test -f foo bar opt c=f optarg=NULL long_idx=-1(INVALID) arg foo arg bar CMD ./getopt_long_test --file foo bar opt c=r optarg=foo long_idx=1 lo[idx].val=r lo[idx].name=file arg bar CMD ./getopt_long_test -r foo bar opt c=r optarg=foo long_idx=-1(INVALID) arg bar CMD ./getopt_long_test --reference foo bar opt c=r optarg=foo long_idx=2 lo[idx].val=r lo[idx].name=reference arg bar ====== As a fix: - change the val field of the --file longoption to be 'f', and put the handling for the obsolete case there. - always reset longindex to an invalid value after each iteration of the getopt_long loop, and check it for being valid before using it.
Created attachment 233799 [details] getopt_long_test.c
Filed with upstream contributor that introduced the bug: meyering@redhat.com
Additional notes: The documentation for glibc's _getopt_internal_r includes this block, that is NOT anywhere else that I can find: LONGIND returns the index in LONGOPT of the long-named option found. It is only valid when a long-named option has been found by the most recent call.
Upstream patch now available. vapier: any objections to applying that patch to current ~arch and stable?
current stable is pointless. dont care about adding to unstable patchset.
coreutils-8.6 is in the tree now and should already have this fix
