AaronBallman wrote: > > and that implies (at least to me) that an expression cannot form an > > infinity to begin with, so the act of trying to expand INFINITY is > > nonsensical in that case, right? > > It's undefined behavior at runtime. > > I don't think we need to worry too much about what the C standard says here; > the language around floating-point types that don't have infinity was written > in the old days before everyone settled on using IEEE math. And I think the > warning we currently produce is probably more helpful in practice than > "INFINITY not defined".
I looked at my meeting notes for discussion of this paper and I think we do need to worry about what the C standard says. From my notes: `The big intent from this change seems to be about making INFINITY to be a feature test macro.`, so if users are going to portably expect `#ifdef INFINITY` to mean that their use of the macro will generate an actual infinity, we really should support that IMO. Also, we can't really rely on UB at runtime because of constant expressions having a constraint that says constant expressions have to evaluate to a constant in the range of representable values for its type. With C23 adding `constexpr`, this constraint matters more for floating-point computations than it did previously. > What I was getting at with the standard version thing is that in standard > versions before C23, I don't think NAN is a reserved identifier if you don't > include math.h. So it's forbidden for float.h to define it. Oh, that's a good point! I'll guard this by C23 and not C99 once we figure out what it means to "support an infinity". https://github.com/llvm/llvm-project/pull/96659 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
