Yes. C++ is silent on the properties of floating-point operations, and that includes the treatment of infinities or NaN. Those are undefined behavior by virtue of not being expressly defined to anything in particular.

C has an Annex that maps floating-point operations to IEEE semantics, including proper NaN treatment. Nobody has proposed something like that for C++, yet.

This needs a full-blown paper targeted at EWG, with rationale etc.

C++ is silent on the properties of floating-point operations, and that includes the treatment of infinities or NaN.

Those are undefined behavior by virtue of not being expressly defined to anything in particular.

I don't understand it. Since the operations defined for float-point types have defaultly covered infinite and 'NaN', why do we say these values are not explicitly expressed and thus UB?

It's implementation-defined whether any infinity and NaN values exist at all.

It's implementation-defined whether any infinity and NaN values exist at all.

That means, all the operations associated with infinity and NaN should be implementation-defined rather than undefined behavior. However, this point is not clear in the current draft. At least, it can be exposed according to the above comment that we all have different opinions regarding floating-point values.

In most subclauses of operations defined in [expr], we merely define rules for arithmetic types without having the special rules for floating-point types. We just have a hazy in floating-point types. Anyway, we have a standard way to acquire infinity and NaN

auto infinity = std::numeric_limits<float>::infinity();
auto QNaN = std::numeric_limits<float>::quiet_NaN();
std::cout<< infinity  << QNaN ; // #1

#1 is UB or implementation-defined? Moreover, when we make these acquired values(by standard ways) participate in the operations defined in [expr], what are the results? UB or implementation-defined, or partial well-defined?

At best, it's implementation-defined.

Note that std::numeric_limits does not necessarily deliver the values you seek, depending on the details of the platform's floating-point format.

There is lots of room for improvement here. One avenue (as I already said) would be to actually specify the relationship to IEC 60559 for those platforms whose floating-point is conforming to that.

Quoting my earlier comment:

This needs a full-blown paper targeted at EWG, with rationale etc.

There is lots of room for improvement here.

Agree. I also don't think we can clarify all of them in an editorial fix. I just want to make this issue be recorded or marked with a CWG tag if possible? Such that we can fix them in the future.

But it's not a CWG issue. There is no defect here. If you want changes, write a paper for EWG.