[BUG] Undefined Behaviour in typedesc_test

[stolk]

Describe the bug

The typedesc_test run does not pass a valgrind run, as data is used before it is initialized.

This causes underfined behaviour.

OpenImageIO version and dependencies

$ ./oiiotool --buildinfo
OIIO 2.6.7.0dev | Linux/x86_64
    Build compiler: clang 18.1 | C++17/201703
    HW features enabled at build: sse2
    No CUDA support (disabled / unavailable at build time)
Dependencies: BZip2 1.0.8, DCMTK NONE, FFmpeg NONE, fmt 10.2.1, Freetype 2.13.2, GIF 5.2.2, Imath 3.1.9, JPEG 80, JXL
    0.12.0, Libheif NONE, libjpeg-turbo NONE, LibRaw NONE, OpenColorIO 2.4.0, OpenCV NONE, OpenEXR 3.1.5, OpenGL, OpenJPEG
    NONE, OpenVDB NONE, PNG 1.6.43, Ptex NONE, Ptex NONE, pybind11 2.11.1, Python3 3.12.3, Qt5 NONE, Qt6 NONE, Robinmap
    1.3.0, TBB 2021.11.0, TIFF 4.5.1, WebP 1.3.2, ZLIB 1.3

To Reproduce

Steps to reproduce the behavior:

1. Build OIIO
2. Run valgrind on typedesc_test binary.

Evidence

==89086== Conditional jump or move depends on uninitialised value(s)
==89086==    at 0x48C199C: fmt::v10::appender fmt::v10::detail::write_float<char, fmt::v10::appender, float>(fmt::v10::appender, float, fmt::v10::format_specs<char>, fmt::v10::detail::locale_ref) (include/OpenImageIO/detail/fmt/format.h:3592)
==89086==    by 0x48C18DC: _ZN3fmt3v106detail5writeIcNS0_8appenderEfTnNSt9enable_ifIXsr17is_floating_pointIT1_EE5valueEiE4typeELi0EEET0_S8_S5_NS0_12format_specsIT_EENS1_10locale_refE (include/OpenImageIO/detail/fmt/format.h:3642)
==89086==    by 0x4912E12: operator()<float> (include/OpenImageIO/detail/fmt/format.h:3796)
==89086==    by 0x4912E12: _ZN3fmt3v106detail20printf_arg_formatterIcEclIfTnNSt9enable_ifIXsr3std17is_floating_pointIT_EE5valueEiE4typeELi0EEEvS6_ (include/OpenImageIO/detail/fmt/printf.h:279)
==89086==    by 0x490C01F: visit_format_arg<fmt::v10::detail::printf_arg_formatter<char>, fmt::v10::basic_printf_context<char> > (include/OpenImageIO/detail/fmt/core.h:1720)
==89086==    by 0x490C01F: void fmt::v10::detail::vprintf<char, fmt::v10::basic_printf_context<char> >(fmt::v10::detail::buffer<char>&, fmt::v10::basic_string_view<char>, fmt::v10::basic_format_args<fmt::v10::basic_printf_context<char> >) (include/OpenImageIO/detail/fmt/printf.h:560)
==89086==    by 0x490A415: std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > fmt::v10::vsprintf<char>(fmt::v10::basic_string_view<char>, fmt::v10::basic_format_args<fmt::v10::basic_printf_context<fmt::v10::type_identity<char>::type> >) (include/OpenImageIO/detail/fmt/printf.h:597)
==89086==    by 0x497772D: std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > fmt::v10::sprintf<char const*, float, char>(char const* const&, float const&) (include/OpenImageIO/detail/fmt/printf.h:613)
==89086==    by 0x497265A: std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > OpenImageIO_v2_6_7::sprint_type<float, float>(OpenImageIO_v2_6_7::TypeDesc, char const*, OpenImageIO_v2_6_7::tostring_formatting const&, float const*) (src/libutil/typedesc.cpp:413)
==89086==    by 0x496EEA8: OpenImageIO_v2_6_7::tostring[abi:cxx11](OpenImageIO_v2_6_7::TypeDesc, void const*, OpenImageIO_v2_6_7::tostring_formatting const&) (src/libutil/typedesc.cpp:634)
==89086==    by 0x125826: void test_type<Imath_3_1::Vec2<float> >(OpenImageIO_v2_6_7::basic_string_view<char, std::char_traits<char> >, OpenImageIO_v2_6_7::TypeDesc, OpenImageIO_v2_6_7::TypeDesc, Imath_3_1::Vec2<float> const&, OpenImageIO_v2_6_7::basic_string_view<char, std::char_traits<char> >) (src/libutil/typedesc_test.cpp:61)
==89086==    by 0x10C107: main (src/libutil/typedesc_test.cpp:159)

With allocation at:

==89086==  Uninitialised value was created by a stack allocation
==89086==    at 0x4977740: fmt::v10::format_arg_store<fmt::v10::basic_printf_context<char>, std::remove_cv<std::remove_reference<float const>::type>::type> fmt::v10::make_format_args<fmt::v10::basic_printf_context<char>, float const>(float const&) (include/OpenImageIO/detail/fmt/core.h:1859)

[stolk]

At the moment it is unclear to me whether this is an OIIO bug or a bug in fmt 10.2.1

I will investigate.