You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
BUG: NrrdIO reads and writes floats locale-independently
All NRRD float parsing funnels through airSingleSscanf() and all float
formatting (header fields and ASCII pixels) through airSinglePrintf().
Both honored the ambient LC_NUMERIC locale: under a decimal-comma locale
(e.g. de_DE.UTF-8) "0.878906" parsed as 0, and the writer emitted
"0,878906", corrupting NRRD spacings, directions, origins, and
ASCII-encoded pixel values in both directions.
Parse with strtod_l() and print with the printf_l() family (glibc/musl
lack printf_l; there printf honors the uselocale() thread-local locale,
so swap it around the print) against one cached "C" locale shared via
privateAir.h. Overflow (ERANGE with +/-HUGE_VAL) and an unobtainable
"C" locale fail the operation instead of yielding a wrong value; ERANGE
underflow is a valid subnormal or zero and is accepted.
With NrrdIO locale-independent by construction, the NumericLocale RAII
guards in itk::NrrdImageIO are unnecessary and are removed; that RAII
mechanism is a no-op on macOS 13 and earlier libc, whose non-_l
strtod/printf ignore the thread-local locale.
itkNrrdLocaleTest now loops over four decimal-comma locales, adds a
write-under-comma-locale round trip, and warns loudly when no comma
locale is installed.
Mirrors the same change on the teem upstream branch
locale-independent-numeric-parse.
0 commit comments