Le 19/09/2022 à 18:17, FX a écrit :
Hi,
2. Add the optional RADIX argument to IEEE_SET_ROUNDING_MODE and
IEEE_GET_ROUNDING_MODE. It is unused for now, because we do not support
floating-point radices other than 2.
If we accept the argument, we have to support it somehow.
So for IEEE_GET_ROUNDING_MODE (*, 10), we should return IEEE_OTHER, shouldn't
we?
I think I disagree. We do not support any real kind with radix 10, so calling
IEEE_GET_ROUNDING_MODE with RADIX=10 is invalid. Or, in another interpretation,
the rounding mode is whatever-you-want-to-call it, since you cannot perform
arithmetic in that radix anyway.
Hmm, not really convinced, but that's a possible interpretation, I guess.
There is no problem for IEEE_SET_ROUNDING_MODE (*, 10) as there is no way this
to be a valid call if radix 10 is not supported, but changing a compile time
error to a runtime unexpected behavior seems like a step backwards.
What do you mean by that? The behavior is not unexpected, the value returned by
IEEE_GET_ROUNDING_MODE for RADIX=10 is irrelevant and cannot be used for
anything useful.
My sentence was about IEEE_*S*ET_ROUNDING_MODE actually.
My point that we previously reported an error (at compile time) to a
user that would try to pass a radix 10 while we now silently do...
something else that was requested (i.e. set the radix 2 rounding mode).
I think it's worth at least documenting that only radix 2 is supported.
