mirror of
https://github.com/HDFGroup/hdf5.git
synced 2026-09-27 04:09:40 +03:00
Scot Breitenfeld
01f6322de0
%.16e always emitted 17 significant digits even for values like 3.0 that don't need them, which a reviewer flagged as needlessly verbose on HDFGroup/hdf5#6153. H5Z__format_double_canonical() now searches increasing %.*g precision, verified by an actual strtod round-trip, falling back toward the full 17 digits only when a value's mantissa doesn't line up with a short decimal. Still forces a decimal point/exponent so TOML types the result as a float, and still guarantees the same bit-exact round-trip. Updated the get_config plugin contract to recommend the same technique (keeping %.16e as an always-valid fallback), the comments that documented the old fixed format, and the h5dump hex-annotation rationale, whose "hex is shorter than decimal" argument no longer held once decimals got shorter too. Also fixed the canonicalization-growth regression test, whose 0x1p0 literal now shrinks under the new format instead of expanding, which had quietly defanged the test it was scaled to break.