On Thu, 1 Sep 2016, Szabolcs Nagy wrote: > it seems that the FLT_EVAL_METHOD change in TS 18661 was a > bad decision: existing code have to be modified to conform > to the new semantics. this situation could have been avoided > by introducing new macros or only changing behaviour when > the user requested it via __STDC_WANT_IEC_60559_TYPES_EXT__ > (consistently with all other library changes..).
You could always raise the issue directly with WG14, since TS 18661 is supposed to be compatible with C11 (cf the issue I raised about whether the formula for DECIMAL_DIG in C11 is normatively required or a minimum). Now a minimal fix for such an issue (interpreted as a DR against C11 rather than against TS 18661-3) to make the definition of FLT_EVAL_METHOD extensible would be to remove the word "negative" in "All other negative values for FLT_EVAL_METHOD characterize implementation-defined behavior.", so making it more like FLT_ROUNDS. Which would allow the value 16 to be used in existing standards modes, but not avoid the need to update existing code to handle it. But you might prefer an interpretation as a DR against TS 18661-3 where the FLT_EVAL_METHOD definition does not have to reflect the new types unless __STDC_WANT_IEC_60559_TYPES_EXT__ is defined accordingly (and maybe for consistency DEC_EVAL_METHOD only has to reflect TS 18661-2 decimal types, not those from 18661-3, unless __STDC_WANT_IEC_60559_TYPES_EXT__ is defined). I expect glibc will be defining __STDC_WANT_IEC_60559_TYPES_EXT__ soon anyway (in its <float.h> wrapper to get FLT128_* definitions from there where possible) so would still need adapting to be optimal with _Float16 compiler support. -- Joseph S. Myers jos...@codesourcery.com
