mask signed char in ctype calls in http_create and _cupsEncodeOption

[tanjiroK-coder]

http_create decides whether a hostname is a bare IPv6 literal by testing its first four bytes with isxdigit, and _cupsEncodeOption decides whether an integer/enum option value is numeric by testing its first byte with isdigit, both handing a plain char straight to the ctype function. The hostname is the connection target and the option value is whatever the caller is encoding, so either leading byte can be >= 0x80; where char is signed that is a negative int, and passing anything other than EOF or an unsigned char value to a ctype function is undefined behaviour, and an out-of-bounds classification-table read on libc builds whose table isn't padded for negative indices. I hit it reading the two sites next to code that already masks the same way, e.g. isspace(*end & 255) earlier in http.c and isxdigit(src[1] & 255) in http-support.c. The fix adds the & 255 mask the rest of the library already uses, so the result is unchanged on common libc and defined everywhere.

Assisted-by: Claude Code:claude-opus-4-8

[michaelrsweet]

I think I want to update the _cups_isXXX functions to include _cups_isxdigit and _cups_isdigit so we can eliminate the masking completely.

[michaelrsweet]

[master 318b6b8] Replace all usage of ctype macros with internal versions to avoid signed char issues (Issue #177)

[tanjiroK-coder]

thanks — the internal _cups_is* functions are a cleaner fix than masking at each call site.