Error due to accessing an entry in argv entry beyond the end of the list

[antiprism]

Some toolkits, like Glut, might process the argument list before the program calls ultragetopt(), rewriting argc and the entries of argv. This can leave a valid option identifier in argv[argc], which ultragetopt accesses and which leads to an error.

The following demonstration program

ultra_test2.zip

reproduces the situation by reducing argc by two before calling ultragetopt, and then reports on the argument list. It accepts options -a and -b, which take parameters.

Test 1: completes correctly
./ultra_test2 -a 1 bbb ccc

Before processing agument list (argc has been reduced by two):
argc = 3
argv[0] = './ultra_test2'
argv[1] = '-a'
argv[2] = '1'

Processing agument list:
option -a read, argument is '1'

After processing agument list:
ultraoptind = 3

Test 2: shows the issue occurring when the argument beyond the truncation point is a valid option identifier.
./ultra_test2 -a 1 -b ccc

Before processing agument list (argc has been reduced by two):
argc = 3
argv[0] = './ultra_test2'
argv[1] = '-a'
argv[2] = '1'

Processing agument list:
option -a read, argument is '1'
option -b missing required argument

After processing agument list:
ultraoptind = 4
ultraoptind is greater than argc

The fix might be to change ultragetopt.c:568

/* Sanity check (These are specified verbatim in SUS) */
if (ultraoptind > argc

to

/* Sanity check (These are specified verbatim in SUS) */
if (ultraoptind >= argc

Adrian.

[kevinoid]

Definitely a bug. I think your fix is correct, but it has been a while since I last worked on this code.

I'm working on adding proper unit and behavior tests as part of the fix, to prevent any accidental regressions. It may take me a little while to complete. If I don't have it done in a few days, feel free to ping this issue.

Thanks again for taking the time to report this issue!

[antiprism]

Thanks for reviewing this so quickly. I'll look out for the update.