Why is this type punning not undefined behavior?

Question

Here is a toy example that I thought would invoke undefined behaviour:

#include <cstdint>
#include <iostream>
#include <vector>

int
main()
{
    std::vector<uint16_t> foo = {0, 0x42F6};
    std::cout << *reinterpret_cast<float*>(foo.data()) << std::endl;
    return 0;
}

I was pretty certain that dereferencing the result of that reinterpret_cast would violate the strict aliasing rules. However:

$ g++ --version
g++ (Ubuntu 5.4.0-6ubuntu1~16.04.10) 5.4.0 20160609
$ g++ -fstrict-aliasing -Wstrict-aliasing -fsanitize=undefined -std=c++14 -o a a.cpp
$ ./a
123

No warnings from the compiler or the UB sanitizer. Why not?

"Undefined behavior" does not guarantee you a compilation error, or a runtime crash. Those are just two possibilities. The range of possibilities includes everything between the program running fine, and your computer exploding into firing, molten, bits of metal. — Sam Varshavchik, Aug 03 '18 at 11:03
I suspect that the sanitizer is more geared towards accidental issues than deliberate ones. — molbdnilo, Aug 03 '18 at 11:23
This violates the [strict aliasing rule](https://stackoverflow.com/a/51228315/1708801) and you can see in that link Tysan is under development to catch strict aliasing violations. UBSan is not expected to catch those. ASan will catch unaligned read/write though. — Shafik Yaghmour, Aug 03 '18 at 13:14

score 6 · Accepted Answer · edited Aug 03 '18 at 11:26

Why is this type punning not undefined behavior?

Your premise is wrong. The behaviour is undefined.

No warnings from the compiler ... Why not?

A compiler is not required to warn about UB. Sometimes it does, when the stars align, but it is in general prohibitively expensive for the compiler to prove the existence of UB. In fact, if it was possible, then the language rules probably would have specified the program to be ill-formed instead.

or the UB sanitizer. Why not?

The UB sanitizer isn't perfect. It cannot detect all UB. Consider filing a feature request for implementing detection of this case - assuming it hasn't already been requested.

score 5 · Answer 2 · answered Aug 03 '18 at 10:46

5

No warnings from the compiler or the UB sanitizer. Why not?

This doesn't mean you do not have undefined behavior. The compiler and sanitizer can do their best to detect it, but it's not guaranteed to catch every occurrence of it.

The only way you can be sure is by reading the Standard and checking whether your usage of reinterpret_cast is well-defined.

answered Aug 03 '18 at 10:46

Vittorio Romeo

90,666
33
258
416

Behavior that's formally UB can be defined by any particular compiler. E.g., without that there would be no way to access a known fixed memory address in some embedded system. So one should better also read the compiler docs. – Cheers and hth. - Alf Aug 03 '18 at 11:29

score 0 · Answer 3 · answered Aug 03 '18 at 15:30

The fact that the Standard does not require implementations to define the behavior of some construct does not imply that implementations intended to be suitable for various purposes shouldn't define it anyway. Many implementations have various options that will cause the compiler to consistently treat some such constructs as defined in ways that are sometimes useful or even necessary to programmers writing certain kinds of code (even though the Standard does not require it).

With regard to your example, there are some implementations where invocation with a suitable combination of options would yield behavior defined precisely as what you see. On many implementations, the required options would include -fno-strict-aliasing, though some may require other options as well. Some implementations, however, especially those where a vector<uin16_t> might not be 32-bit aligned, and where loading a float will fail if it isn't 32-bit aligned, may not support any combination of options that would define the behavior.

Slightly confusing the matter, however, is the fact that even when such options are not used (or not supported), many implementations will treat those constructs in the a fashion that will often--though not reliably--coincide with the way they would if such options were specified and supported. This can make it difficult to determine whether a piece of code can be expected to work consistently, or may sometimes work and sometimes fail, in unpredictable fashion.

Why is this type punning not undefined behavior?

3 Answers3

Linked