[cfp-interest 3720] Re: Comments on cfp3691 RoundingMode

[Damian McGuckin]

On Mon, 10 Nov 2025, Jim Thomas wrote:

> 5.3.5.3.3#23 FLT_ROUNDS (applying only to addition) is a legacy macro. 
> We?ve had no WG14 or user requests to change the specification.

I have largely reverted to the old words.

> Confusion and Vagueness
> My understanding: A mode is a variable.

The fact that we have a different interpretation just says the words being 
used in C2Y currently are unclear. I asked some random people to explain
the text in C2Y to me and they all got confused.

My understanding is that a mode is like a state or enum. There are five 
possible "rounding direction mode"s each of which are invariant and have a 
1:1 relationship with an ISO/IEC 60559 rounding direction attribute. The 
"current rounding direction mode" or the "default rounding direction mode" 
can have one of those five invariant "rounding direction modes" (or some
other value if an implementation defines it).

See my explanations. They may still be inadequate. They most likely are,

C never lets you get directly at the "current rounding direction mode". 
The fegetround() routine returns a value which is equal to one of the 
"rounding direction macros" and which reflects the "current rounding 
direction mode" while fesetround() accepts an argument of a "rounding 
direction macro" which you can use to change the "current rounding 
direction mode" if the implementation allows you to change it at all 
during execution, i.e. the mode is dynamic. Those macros are normally bit 
masks from the control registers but we do not need to tell people that.

> 7.6.6.3#2 says the function "gets the current value of the dynamic rounding
> direction mode?, which is what it does.

No.

It returns a value which is a "rounding direction macro" which reflects 
the current "rounding direction mode". C2Y uses the word "reflects" for 
this sort of relationship. In an implementation which does not allow 
dynamic rounding, it returns the default rounding direction mode which is 
also the current one. For an implementation which allows dynamic rounding 
direction modes, it always returns the current rounding direction mode, 
which by the way is also the default rounding direction mode if no 
execution time change of that has been made to occur.

> 7.6.6.3#3 says the function returns "the value of the rounding direction
> macro representing the current dynamic rounding direction or ....? Here ?the
> current dynamic rounding direction? is the value of the dynamic rounding
> direction mode as just referred to in #2. The value of the mode is generally
> better not referred to as a mode.

See above.

> A table, similar to the one suggested, listing the rounding directions and
> the rounding direction macros that represent them seems like a good idea.
> Maybe in 7.6.1#14.

> I don?t see a benefit of changing the comma to ?with?.

It makes it easier to deal with in sentences with punctuation.

> F.5#5
> Yes, add ?mode? in first sentence.

> Given a table (like above), I don?t thank any change is needed in the 
> second sentence. The functions probably don?t know what the effective 
> rounding direction will be when they are called, though the 
> implementation might have rounding-direction-specific versions of the 
> functions to use in the generated code where the rounding direction is 
> known at translation time. "If the rounding direction can be upward or 
> downward" is the general condition for ruling out implementation that 
> just negates the converted unsigned sequence.

I got rid of the mentioned "rounding direction" to avoid confusion.

Thanks - Damian