2 ms·
For nearly all of the last 10 years, I have been working on the specific topic of how to better predict what a C program can do (and in particular, correctly pr
by pascal_cuoq 12y ago
For nearly all of the last 10 years, I have been working on the specific topic of how to better predict what a C program can do (and in particular, correctly predict that a C program will behave well). This is a shorter time than 17 years, but it is more focused than using C as a tool for actually achieving something else, where you aren't thinking about the specifics of C most of the time, hopefully.
Despite this, a fortnight ago I was caught off-guard by GCC 4.9's choice of compiling the program in http://pastebin.com/raw.php?i=fRbGfQ6p http://pastebin.com/raw.php?i=fRbGfQ6p to an executable that displays “p is non-null” followed by “p:(nil)”.
There has to be a way out of this. Seriously. Most C programmers neither asked for nor deserve this.
- DSMan195276 12y agoIf you don't mind me taking a guess, is it because calling memcpy with NULL is undefined-behavior, thus GCC assumes p must be non-null and thus the if (p) is redundant and x must equal 1?
- pascal_cuoq 12y agoExactly. Propagating the information that p was passed as argument to memcpy and thus must be non-null is a new GCC 4.9 optimization (some discussion here: http://stackoverflow.com/questions/5243012/is-it-guaranteed-to-be-safe-to-perform-memcpy0-0-0 http://stackoverflow.com/questions/5243012/is-it-guaranteed-... ).