<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<div style="direction: ltr; font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
To answer the last question, yes, C has the deprecated attribute (which can be put on function declarations), along with the standard text terms of things like obsolescent.</div>
<div style="direction: ltr; font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="direction: ltr; font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Whether we want to take any of those approaches or not is another story. Also, even if the function is marked deprecated, we do still have to answer Huberts query so getting an agreement in CFP for that is still on the table.</div>
<div style="direction: ltr; font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div id="ms-outlook-mobile-signature">
<p class="xxmsonormal" style="margin: 0in;"><span style="color: rgb(33, 33, 33);">Regards,<br>
<br>
<b>Rajan Bhakta</b><br>
</span> </p>
</div>
<div id="mail-editor-reference-message-container">
<div class="ms-outlook-mobile-reference-message skipProofing">
<meta name="Generator" content="Microsoft Exchange Server">
</div>
<div style="padding: 3pt 0in 0in; border-width: 1pt medium medium; border-style: solid none none; border-color: rgb(181, 196, 223) currentcolor currentcolor;">
<div class="ms-outlook-mobile-reference-message skipProofing" style="text-align: left; font-family: Aptos; font-size: 12pt; color: black;">
<b>From: </b>cfp-interest <cfp-interest-bounces@oakapple.net> on behalf of Damian McGuckin <damianm@esi.com.au><br>
<b>Date: </b>Thursday, May 14, 2026 at 11:00 PM<br>
<b>To: </b>CFP Interest <cfp-interest@oakapple.net><br>
<b>Subject: </b>[EXTERNAL] [cfp-interest 3938] nexttoward()<br>
<br>
</div>
</div>
<div class="PlainText" style="font-size: 11pt;"><br>
Hubert's email says:<br>
<br>
The description of nexttoward has:<br>
<br>
The nexttoward functions are equivalent to the nextafter functions<br>
except that the second parameter has type long double or<br>
_Decimal128 and the functions return the numerical value resulting<br>
from converting y to the return type of the function if x equals y<br>
<br>
and the description of nextafter has:<br>
<br>
The nextafter functions determine the next representable value, in<br>
the return type of the function, after x in the direction of y,<br>
where x and y are first converted to the return type of the<br>
function. The nextafter functions return the numerical value of y<br>
if x equals y.<br>
<br>
Hubert suggests:<br>
<br>
The nexttoward wording establishes that its second parameter has a<br>
different type than that of nextafter, but it does not establish<br>
that the second parameter is not "first converted to the return<br>
type of the function".<br>
and<br>
Perhaps the description of nextafter should say "where each of x<br>
and y is first converted to the type of the respective parameter"?<br>
<br>
The problem is the wording of nextafter is Hubert hints at. The problem is<br>
thatr Hubert is thinking that x and y are arguments. They are parameters<br>
so they already have the return type of the function so there is no need<br>
of any conversion.. The is not the first time, as we saw in the April<br>
meeting, that there is confusion between arguments and parameters.<br>
<br>
I would argue that the words<br>
<br>
where x and y are first converted to the return type of the<br>
function.<br>
<br>
are superfluous and can be deleted. That conversion never occurs.<br>
<br>
And if one has a macro definition of nextafter(), then surely it is the<br>
responsibility of the implementation of the macro to ensure that this<br>
macro emulates what happens across a function call and converts any<br>
argument to the type of the equivalent parameter without words to spell<br>
that out somehow needing to appear in 7.12.12.3.<br>
<br>
Or, we could take a radical approach:<br>
<br>
Given that the IEEE 754 1985 functional of nextafter() was replaced 2<br>
decades ago in IEEE 754 2008 and 2019 with the pair of routines nextup()<br>
and nextdown(), and that nexttoward() is purely a feature of ISO/IEC<br>
60559, can it be deprecated.<br>
<br>
Is there a mechanism for this sort of thing?<br>
<br>
Thanks - Damian<br>
_______________________________________________<br>
cfp-interest mailing list<br>
cfp-interest@oakapple.net<br>
<a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__mailman.oakapple.net_mailman_listinfo_cfp-2Dinterest&d=DwICAg&c=BSDicqBQBDjDI9RkVyTcHQ&r=XTIN0AwPKAf2bIKNxlzdeqggAytE5h-JEusWpx9MXwc&m=YqmlhOpi7Hnk7EdPjflUKqsZsAifDji1UWJMCXr9pQjbToNmvEQnfwSNRvHAHhFU&s=9EGX5uVefqQgptMMVIbdD5j-O364z1eY4O7SQQ9u2t0&e=" data-outlook-id="437f1995-3edf-4b75-9750-d8a8cf435efc">https://urldefense.proofpoint.com/v2/url?u=http-3A__mailman.oakapple.net_mailman_listinfo_cfp-2Dinterest&d=DwICAg&c=BSDicqBQBDjDI9RkVyTcHQ&r=XTIN0AwPKAf2bIKNxlzdeqggAytE5h-JEusWpx9MXwc&m=YqmlhOpi7Hnk7EdPjflUKqsZsAifDji1UWJMCXr9pQjbToNmvEQnfwSNRvHAHhFU&s=9EGX5uVefqQgptMMVIbdD5j-O364z1eY4O7SQQ9u2t0&e=</a><br>
</div>
</div>
</body>
</html>