<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div><br></div><div><blockquote type="cite"><b style="font-family: Times; font-variant-ligatures: normal; orphans: 2; widows: 2; text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial;">Damian McGuckin</b><span style="font-family: Times; font-variant-ligatures: normal; orphans: 2; widows: 2; background-color: rgb(255, 255, 255); text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial;"> </span><a href="mailto:cfp-interest%40oakapple.net?Subject=Re%3A%20%5Bcfp-interest%203720%5D%20Re%3A%20Comments%20on%20cfp3691%20RoundingMode&In-Reply-To=%3C919032e-6c28-7e53-58cd-96d4fdfdfc71%40esi.com.au%3E" title="[cfp-interest 3720] Re: Comments on cfp3691 RoundingMode" style="font-family: Times; font-variant-ligatures: normal; orphans: 2; widows: 2;">damianm at esi.com.au</a><br style="font-family: Times; font-variant-ligatures: normal; orphans: 2; widows: 2; text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial;"><i style="font-family: Times; font-variant-ligatures: normal; orphans: 2; widows: 2; text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial;">Tue Nov 11 00:09:53 PST 2025</i><hr style="font-family: Times; font-variant-ligatures: normal; orphans: 2; widows: 2; text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial;"><pre style="text-wrap-mode: wrap; font-variant-ligatures: normal; orphans: 2; widows: 2; text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial;">On Mon, 10 Nov 2025, Jim Thomas wrote:

><i> 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>

I have largely reverted to the old words.

><i> Confusion and Vagueness

> My understanding: A mode is a variable.

</i>

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).

</pre></blockquote>C2Y 7.6.1 says: "A <i>floating-point control mode</i> is a system variable whose value may be set by the user to affect the subsequent behavior of floating-point arithmetic.”<div><br></div><div>The meaning of “mode" in IEEE 754 is the same.<br><div><br></div><div>754-1985 has the definition:</div><div><br></div><blockquote style="margin: 0px 0px 0px 40px; border: medium; padding: 0px;"><div><b>mode</b>. A variable that a user may set, sense, save, and restore to control the</div><div>execution of subsequent arithmetic operations. </div></blockquote><div><br></div><div>754-2019 refers to the “dynamic-mode variable”, e.g. in: "The implementation initializes a dynamic-mode variable to the default value for the dynamic mode."</div><div><br></div><div>Speaking loosely one might say "the rounding direction mode is “upward”." This is a casual way of saying "the value of the rounding mode variable is the “upward” rounding direction." Similarly one might say "x is zero" to mean "the value of the x variable is zero". I suspect a reader's thinking of “rounding direction mode” as referring to a value of the rounding direction mode variable is harmless, though not strictly correct per established definitions.</div></div><blockquote type="cite"><pre style="text-wrap-mode: wrap; font-variant-ligatures: normal; orphans: 2; widows: 2; text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial;">

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.

><i> 7.6.6.3#2 says the function "gets the current value of the dynamic rounding

> direction mode?, which is what it does.

</i>

No.

</pre></blockquote><div>fegetround determines (gets) the value of the rounding direction mode. How it represents that mode value to the caller is stated in the Returns section. It has to get the mode value to know what to return. The choice of the word “gets” vs “determines” comes from “get(ter) and set(ter)” being common in computer science. AI says a getter "provides controlled access to the internal state of an object without directly exposing the attribute”, which is what happens with fegetround.</div><div><br></div><blockquote type="cite"><pre style="text-wrap-mode: wrap; font-variant-ligatures: normal; orphans: 2; widows: 2; text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial;">

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.

</pre></blockquote><blockquote type="cite"><pre style="text-wrap-mode: wrap; font-variant-ligatures: normal; orphans: 2; widows: 2; text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial;">

><i> 7.6.6.3#3 says the function returns "the value of the rounding direction

</i>><i> macro representing the current dynamic rounding direction or ....? Here ?the

</i>><i> current dynamic rounding direction? is the value of the dynamic rounding

</i>><i> direction mode as just referred to in #2. The value of the mode is generally

> better not referred to as a mode.

</i>

See above.

><i> A table, similar to the one suggested, listing the rounding directions and

> the rounding direction macros that represent them seems like a good idea.

</i>><i> Maybe in 7.6.1#14.

</i>

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

</i>

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

</pre></blockquote>Is it a problem if in quotes, e.g. “to nearest, ties to even”? References to the rounding directions shown in a table should probably be quoted.</div><div><br></div><div>- Jim Thomas<br><blockquote type="cite"><pre style="text-wrap-mode: wrap; font-variant-ligatures: normal; orphans: 2; widows: 2; text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial;">

><i> F.5#5

> Yes, add ?mode? in first sentence.

</i>

><i> Given a table (like above), I don?t thank any change is needed in the 

</i>><i> second sentence. The functions probably don?t know what the effective 

</i>><i> rounding direction will be when they are called, though the 

</i>><i> implementation might have rounding-direction-specific versions of the 

</i>><i> functions to use in the generated code where the rounding direction is 

</i>><i> known at translation time. "If the rounding direction can be upward or 

</i>><i> downward" is the general condition for ruling out implementation that 

> just negates the converted unsigned sequence.

</i>

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

Thanks - Damian

</pre><br></blockquote></div><div><br></div><div><br></div></body></html>