3 ms·
Undefined and implementation-defined behaviour are tricky. They've been doing a better job of it recently, but I do wish compilers warned you more when encounte
by pmjordan 16y ago
Undefined and implementation-defined behaviour are tricky. They've been doing a better job of it recently, but I do wish compilers warned you more when encountering code with undefined behavior. Sometimes it's very hard or impossible to detect reliably, for example when doing pointer arithmetic acrobatics. But things like modifying a variable twice within a sequence point, or reading potentially uninitialised variables should have the compiler screaming at you by default.
- mfukar 16y agogcc (4.3.4 on my box) is pretty vocal and explicit about all the shenanigans you mentioned.
- pmjordan 16y agoGCC 4 has seen big improvements in that area, especially with -Wall. Other compilers (except clang) not so much. FWIW, GCC 4.2.1 on OSX 10.6 silently accepts x += ++x; by default. -Wall catches it, at least. I'm trying to think of a reason why the warning might not be on by default - I can only assume it's either lumped in with some other, less reliable undefined behaviour detection, such as aliasing. -Wall doesn't even catch trivial cases of aliasing though, such as int* y = &x; x += ++*y; Maybe it's the default in a newer version, or this is Apple messing with me, not GNU.
- jedbrown 16y agoBoth gcc-4.5.1 and clang-1.1 (from LLVM 2.7) both silently accept the second case with -Wall -Wextra -pedantic.
- joe_bleau 16y agoPC-lint (http://www.gimpel.com/ http://www.gimpel.com/) gives a "Warning 564: variable 'x' depends on order of evaluation" for your first example, but is silent on the second.