[cfp-interest 3940] Re: nexttoward()

[RAJAN BHAKTA]

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.

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.


Regards,

Rajan Bhakta


From: cfp-interest <cfp-interest-bounces at oakapple.net> on behalf of Damian McGuckin <damianm at esi.com.au>
Date: Thursday, May 14, 2026 at 11:00 PM
To: CFP Interest <cfp-interest at oakapple.net>
Subject: [EXTERNAL] [cfp-interest 3938] nexttoward()


Hubert's email says:

The description of nexttoward has:

         The nexttoward functions are equivalent to the nextafter functions
         except that the second parameter has type long double or
         _Decimal128 and the functions return the numerical value resulting
         from converting y to the return type of the function if x equals y

and the description of nextafter has:

         The nextafter functions determine the next representable value, in
         the return type of the function, after x in the direction of y,
         where x and y are first converted to the return type of the
         function. The nextafter functions return the numerical value of y
         if x equals y.

Hubert suggests:

         The nexttoward wording establishes that its second parameter has a
         different type than that of nextafter, but it does not establish
         that the second parameter is not "first converted to the return
         type of the function".
and
         Perhaps the description of nextafter should say "where each of x
         and y is first converted to the type of the respective parameter"?

The problem is the wording of nextafter is Hubert hints at. The problem is
thatr Hubert is thinking that x and y are arguments. They are parameters
so they already have the return type of the function so there is no need
of any conversion.. The is not the first time, as we saw in the April
meeting, that there is confusion between arguments and parameters.

I would argue that the words

         where x and y are first converted to the return type of the
         function.

are superfluous and can be deleted.  That conversion never occurs.

And if one has a macro definition of nextafter(), then surely it is the
responsibility of the implementation of the macro to ensure that this
macro emulates what happens across a function call and converts any
argument to the type of the equivalent parameter without words to spell
that out somehow needing to appear in 7.12.12.3.

Or, we could take a radical approach:

Given that the IEEE 754 1985 functional of nextafter() was replaced 2
decades ago in IEEE 754 2008 and 2019 with the pair of routines nextup()
and nextdown(), and that nexttoward() is purely a feature of ISO/IEC
60559, can it be deprecated.

Is there a mechanism for this sort of thing?

Thanks - Damian
_______________________________________________
cfp-interest mailing list
cfp-interest at oakapple.net
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=
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20260515/71cda309/attachment-0001.htm>