[tanjiroK-coder]

Commit 24ec82a replaced the (*s & 255) < ' ' checks in json.c with the new _cups_iscntrl helper, but the helper compares its int argument directly and every call site hands it a plain char. On platforms where char is signed (x86_64, Apple arm64) any UTF-8 byte at or above 0x80 is negative, so ch < ' ' is true and the byte is classified as a control character. cupsJSONImportString then rejects {"name":"José"} as invalid JSON, which breaks parsing of OAuth metadata, token and userinfo responses, JWKS and JWT claims that carry a non-ASCII name, and cupsJSONExportString writes each such byte as �, so strings libcups stores or signs are silently corrupted. The same helper also handles the password prompt in usersys.c, the debug printf escaping in string.c and three spots in ipptool, which regressed the same way. Masking the argument to an unsigned byte inside the helper restores the pre-24ec82a behavior at every call site without touching the callers, in line with the direction you took for #177. The testjson addition imports a raw UTF-8 string, checks the value, and compares the export against the input; it fails on master with "Invalid JSON data" and passes with the fix.

Assisted-by: Claude

[michaelrsweet]

[master 730d4b7] Fix signed char issue in new _cups_iscntrl function (Issue #184)

[tanjiroK-coder]

Thanks for picking this up in 730d4b7.