Old GCC easter egg (aka implementation-defined behavior)
1–7 of 7 posts
Re: Old GCC easter egg (aka implementation-defined behavior)
#2Undefined 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.
Re: Old GCC easter egg (aka implementation-defined behavior)
#3Undefined 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 variabl…
gcc (4.3.4 on my box) is pretty vocal and explicit about all the shenanigans you mentioned.
Re: Old GCC easter egg (aka implementation-defined behavior)
#4Undefined 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 variabl…
gcc (4.3.4 on my box) is pretty vocal and explicit about all the shenanigans you mentioned.
GCC 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;
int* y = &x;
x += ++*y;
Re: Old GCC easter egg (aka implementation-defined behavior)
#5Earlier quoted context omitted.
gcc (4.3.4 on my box) is pretty vocal and explicit about all the shenanigans you mentioned.
GCC 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 e…
Both gcc-4.5.1 and clang-1.1 (from LLVM 2.7) both silently accept the second case with -Wall -Wextra -pedantic.
Re: Old GCC easter egg (aka implementation-defined behavior)
#6I'm somewhat disappointed that he referred to the last error message as "cryptic" - it's a nod to the old text based game "Adventure"
Re: Old GCC easter egg (aka implementation-defined behavior)
#7Earlier quoted context omitted.
gcc (4.3.4 on my box) is pretty vocal and explicit about all the shenanigans you mentioned.
GCC 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 e…
PC-lint (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.