fix(#2097): escape trailing-NUL signatures so XML and JSON round trip

[colourbill-ctrl]

Part of #2097 — the trailing-NUL half. Confirming @xsscx's RCA in full.

The defect

icGetSigStr() (IccProfLib/IccUtil.cpp:1117) renders a signature as four
characters when it can and falls back to an unambiguous "%08Xh" escape when it
cannot. The fallback was selected only by a zero byte followed by a non-zero
one. A signature whose zeros were all trailing therefore took the
four-character path, where the zero simply terminated the C string the loop was
filling:

0x44555000  ->  "DUP"          icGetSigStr()   three characters, zero eaten
"DUP"       ->  0x44555020     icGetSigVal()   three characters right-padded 0x20

Both machine-format writers serialize tag-table identifiers through this display
helper — IccProfileXml.cpp:273 and IccProfileJson.cpp:228 — so the value was
rewritten on every round trip in either format.

Measured

Tracked fixture Testing/Encoding/ISO22028-Encoded-sRGB.xml plus one
signatureType tag carrying 0x44555000:

lane	before	after
ICC -> XML -> ICC	44 55 50 00 -> 44 55 50 20	byte-exact
ICC -> JSON -> ICC	44 55 50 00 -> 44 55 50 20	byte-exact
ICC -> JSON -> ICC -> XML -> ICC	corrupted	byte-exact

Exactly one byte moved, at offset 172. Both the correct and the corrupted
profile validate as "Profile is valid for version 5.00" — 0x44555020 is
merely unregistered, not malformed — which is why the regression asserts bytes
rather than a validation report.

Checked against the live registry (registry.color.org/tag-signatures,
2026-08-11): six assigned ranges open on such a signature — 44555000 and
64757000 (Dupont), 544B0000, 546B0000, 744B0000, 746B0000
(Tektronix). All six now survive both formats.

The fix

Any zero byte selects the hex form, which icGetSigVal() parses back exactly
(its 9-character case). Every reader on both sides already routes through
icGetSigVal — XML via icXmlStrToSig, JSON directly — so this is writer-only
and symmetric.

icGetColorSigStr() carried the identical condition and is likewise a
serializer (<DataColourSpace>, <PCS>, <MCS>, <SpectralPCS>), so it gets
the same treatment.

Deliberately not addressed here

The seventh row of the issue's table, 00000000 (Sun Microsystems' assigned
range start), still round-trips to 4E554C4C. icGetSigStr(0) returns the
literal text "NULL", which is a display convention the call sites work
around by writing an empty value for zero — the #1356 / #1361 / #1843 family,
which has three regressions of its own and whose readers map empty text back to
zero. Changing it would alter iccDumpProfile output for every absent
signature, and the XML reader rejects an empty TagSignature attribute
outright, so a fix for the all-zero tag-table identifier needs a design
decision rather than a formatter change. Flagged for triage, not silently
folded in.

Regression

iccdev.issue-2097-nul-signature-roundtrip — new script test, fixture derived
from tracked XML by awk (no new binaries). Four sections: the reported example
in both formats; the five remaining registry signatures; the cross-format lane;
and an anti-overfit check — escaping every signature to hex would satisfy the
first three while making every serialized profile unreadable, so a printable
signature must still be written as its four characters. Verified red against a
reverted library (fails at the first assertion) and green on restore.

Pre-flight

profile	result
clang-18 -Wall -Wextra -Wpedantic -Werror Release	built 100%, 0 warnings
GCC 15.2.0 in the pinned CI container, strict + LTO (strict warnings ENABLED)	built 100%, 0 warnings
clang-18 ASAN+UBSAN Debug strict	built 100%, 0 warnings; new test clean under detect_leaks=1
full local ctest (serial and -j4)	175/176; the one failure is iccdev.spectral-tiff-preview, a local-only missing python imagecodecs
shellcheck 0.9.0 on the new script	rc=0

The three sibling zero-signature regressions (#1356, #1361, #1843) all still
pass, confirming the "NULL" convention is untouched.

[xsscx]

Deliberately not addressed here
The seventh row of the issue's table, 00000000 (Sun Microsystems' assigned
range start), still round-trips to 4E554C4C. icGetSigStr(0) returns the
literal text "NULL", which is a display convention the call sites work
around by writing an empty value for zero — the #1356 / #1361 / #1843 family,
which has three regressions of its own and whose readers map empty text back to
zero. Changing it would alter iccDumpProfile output for every absent
signature, and the XML reader rejects an empty TagSignature attribute
outright, so a fix for the all-zero tag-table identifier needs a design
decision rather than a formatter change. Flagged for triage, not silently
folded in.

[xsscx]

2026-08-11 10:21:06 UTC

[xsscx]

PR Status

2026-08-11 10:26:35 UTC

Monitoring

Potentially a transient error... waiting on the job to complete and review logs..

CI Error

Setting up auth
Fetching the repository
Removing auth
Error: The process 'C:\Program Files\Git\bin\git.exe' failed with exit code 128

[xsscx]

PR Status

2026-08-11 10:37:11 UTC

1. CI Transient Issue
2. PR Code Review is 100% GOOD on Local W5 WinTel