int a; …; (a == a) fails?

Question

if we set float and double type to NaN then they are not equal to anything including themselves.
can such a thing happens for

Answer 1

How about

unsigned int a = -1;
if (a == (unsigned char) a) { //returns false
(...)

Answer 2

This perfectly possible if you compare uninitialized variables.

In C++ language an uninitialized variable is not guaranteed to hold a stable value. In theory operating with uninitialized values produces undefined behavior. In practice reading the value of the same uninitialized variable multiple times can easily result in different values being read. The most obvious practical reason for this is that the variable was optimized to some CPU register.

In order to manage the limited amount of CPU registers efficiently, optimizing compilers operate with the notion of value lifetime of a variable. Value lifetime is essentially the period during which the variable holds a specific stable value. Value lifetime begins when the variable is initialized and ends when it is re-initialized to another value (or when its accessed for the very last time). Within the period of "value lifetime", the value must be stable, so the CPU register cannot be used for other purposes (or it have to be carefully saved and restored every time it is used for other purposes).

Outside the period of value lifetime, there's no need to preserve the value of the register, so it can be freely used for other purposes. For this reason, if some variable is represented by a CPU register, but not initialized (i.e. if its value lifetime hasn't begin yet) its observed value can change absolutely unpredictably, producing the new value every time the variable is read, because the contents of the corresponding CPU register changes for some unrelated reasons.

This might easily result in a == a evaluating to false with uninitialized a. Of course, it is rather surprising to see it happen for two reads that appear to be located so "close" together. But it still can happen. This behavior is prefectly standard. The standard does not guarantee the stability of an initialized variable.

Answer 3

NaN is the only value for a==a return false.

And int doesn't support a NaN value. So no you can't have this situation with int.

Another note, to check if a value is NaN you should use isnan() not a==a.

---

On the same topic :

• Negative NaN is not a NaN?

Answer 4

It cannot happen when you compare plain initialized int variables.

It can happen for int comparisons when you reference a hardware register, e.g. something like:

*timeRegister == *timeRegister

It could also happen when you compare a volatile int variable to itself which is modified by a signal-handler during the comparison.

Answer 5

Would depend on the compiler optimization maybe; look at the disassembly. If it uses binary 'and' it & check the flags after it will fail if a is zero.

Answer 6

Since C++20, the answer (for initialized variables) is no.

As proposal P0907 explains, signed integers previously allowed various value representations, including "the existence of an extraordinary value which traps, extra padding bits, [and] integral negative zero." (Hence Potatoswatter's answer that, in theory, NaN values for ints were possible.) In practice, though, every machine running C++ uses a "normal" two's complement representation for signed integers.

Supporting that proposal, the C++ standards committee decided to standardize two's complement and to disallow extraordinary values. Now, the value representation of signed integers is fixed, and while integers can also have padding bits, the standard stops them from doing anything unusual: (basic.fundamental)

Each set of values for any padding bits ([basic.types]) in the object representation are alternative representations of the value specified by the value representation. [Note: Padding bits have unspecified value, but cannot cause traps. In contrast, see ISO C 6.2.6.2. — end note]

Therefore, ints have no extraordinary values that could produce NaN-like behavior.