[Carmel0]

Follow-up to #196.

#196 fixed an uninitialized read found by QUniSan during fuzzing. I then asked
GPT-5.6-sol to scan for similar issues; it found this remaining instance, which
was subsequently reproduced with MemorySanitizer.

cups_lang_new() receives the langname buffer from cupsLangFind(). When a
strings directory has been set with cupsLangSetDirectory() and
<dir>/<language>.strings does not exist, it checks language[2] to decide
whether to retry with the two-letter base language. cupsCopyString() only
initializes the copied bytes and the terminating null, so for a one-character
name such as the POSIX "C" locale, language[2] is still uninitialized—the
same byte #196 guarded in cupsLangFind().

Reproducer

Build with MemorySanitizer:

./configure --enable-debug --disable-shared --with-sanitizer=memory \
    CFLAGS="-O1 -g -fno-omit-frame-pointer" CPPFLAGS=""
make -C cups libcups3.a testlang

Then call:

cupsLangSetDirectory("/nonexistent-dir");
cupsLangFind("C");

MemorySanitizer reports:

==32==WARNING: MemorySanitizer: use-of-uninitialized-value
    #0 0x562d32604118 in cups_lang_new /src/cups/language.c:657:29
    #1 0x562d32604118 in cupsLangFind /src/cups/language.c:132:12
    #2 0x562d32603782 in main /probe/langprobe.c:48:12

SUMMARY: MemorySanitizer: use-of-uninitialized-value
/src/cups/language.c:657:29 in cups_lang_new

Valgrind with --track-origins=yes additionally traces the value to the stack
allocation in cupsLangFind() at language.c:107.

Check the string length instead of indexing position 2. The same probe cases
are clean under MemorySanitizer and Valgrind after the change, and testlang
passes. Full cups and ippeveprinter builds also complete without warnings.

Assisted-by: OpenAI Codex:GPT-5.6-sol
Assisted-by: OpenAI Codex:GPT-5

[michaelrsweet]

[master 137b64b] More tweaking for POSIX locale.