Description of problem: argp() relies on broken library functions to test the integer argp_option.key parameter. If that int falls outside of the testable parameters of isprint(), the program will segfault. Version-Release number of selected component (if applicable): How reproducible: every time Steps to Reproduce: 1. compile a program using argp() argument parsing, use as keys valid ints which the isprint() function cannot digest. Actual results: seg fault on startup. Expected results: correct running program Additional info: See FC5 bug 189525 for a discussion of how the badly defined C99 spec lets isprint(int) legally segfault for valid ints that fall outside of the range representable via unsigned char. Unfortunately, the argp_option structure contains: `int key' The integer key provided by the current option to the option parser. If KEY has a value that is a printable ASCII character (i.e., `isascii (KEY)' is true), it _also_ specifies a short option `-CHAR', where CHAR is the ASCII character with the code KEY. The value of key is tested by isprint(), not isascii(). Legal values of the key can thus cause the program to segfault. Either the documentation for argp needs to be updated, or the argp() parsing function should check the key before passing it to isprint(). As per the spec: `` int isalnum(int c); ... The c argument is an int, the value of which the application shall ensure is representable as an unsigned char or equal to the value of the macro EOF. If the argument has any other value, the behavior is undefined.'' The argp() function does not ensure the representability of its key as an `unsigned char or ... EOF' before calling isprint(). The documentation does not demand that the argp() caller perform that check. This is a bug.
Helpful comments from the gnu-lib mailing list have pointed out that this bug was fixed in argp.h in july of last year. the change in argp.h is basically: int __key = __opt->key; - return __key > 0 && isprint (__key); + return __key > 0 && __key <= UCHAR_MAX && isprint (__key); can this be pushed into FC glibc please...
Should be fixed in glibc-2.4.90-1 in rawhide.