[Cfp-interest 2205] Re: contradiction about the INFINITY macro

[Vincent Lefevre]

On 2021-10-05 11:13:59 -0700, Jim Thomas wrote:
> I suggest changing 
> 
> 	else to a positive constant of type float that overflows at translation time
> 
> to
> 
> 	else to an expression of type float that overflows with positive sign at translation time
> 
> This is intended to allow the implementation to use whatever magic is needed.
> 
> I had lost track of this issue and neglected to put it on the September CFP agenda. If we can converge on a resolution, and if no one objects, I can submit a paper with our agreed suggested change before the deadline. Please send any comments ASAP.

Wouldn't it be better to require INFINITY to be defined if and only if
the type float supports infinity, so that this can be tested?

In the comp.std.c thread "contradiction about the INFINITY macro"
https://groups.google.com/g/comp.std.c/c/XCzEiwD9n_A I started,
Keith Thompson said:

  (I wonder if it would have been more useful to require that INFINITY not
  be defined unless it can be defined as an actual infinity, but I haven't
  given it a lot of thought.)

Note that in the current standard and with the suggested change, if
infinity is not supported, then the use of INFINITY yields an overflow
at translation time, which implies undefined behavior (even if the
value will never be used). This is rather useless.

Moreover, shouldn't infinity be supported for all FP types or none?
Keith Thompson said:

  The INFINITY and NAN macros are defined only for float.  I think the
  assumption is that either all floating-point types support infinities,
  or none do, and likewise for NaNs.  On the other hand, fpclassify() is a
  macro that can be applied to an expression of any floating-point type.

-- 
Vincent Lefèvre <vincent at vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)