> Not becoming an idiot is the best solution [...] [...] but don't assume that you'll ever be good enough to not be an idiot. Try to converge on it if possible through. I'm still an idiot with C and I've been doing it since 1997

We have wildly differing definitions of "best solution". I like solutions to be actually achievable, for example.

The problem is, by that metric, everyone is an "idiot." There isn't a C programmer alive who hasn't been bitten by most, if not all, of these types of memory bugs.

There's a reason that the safety razor became more popular than the straight razor.

If I knew someone who didn't become friendly to me for the first 25 years of our relationship, I wouldn't call them friendly.

> Not becoming an idiot is the best solution

"Best" by what quality metric? "Not becoming an idiot" is difficult and time-consuming. Furthermore, there's no reliable way to determine if you have in fact succeeded in ceasing to be an idiot because part of the license that compilers have when encountering undefined behavior is to mask it. So even if your code compiles without warnings and passes all tests that is no guarantee that you have ceased to be an idiot. So requiring a compiler to do something more reasonable in the face of undefined behavior than reformat your hard drive (or at least to make it an option) is not an unreasonable position.

How long does it take? I'm at about 20 years and still haven't made it.

Well I see it more like it takes e^-x years i.e. it never converges on total non-idiocy but you can get pretty close.

(been doing it for 17 years)

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 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.

If 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?

Exactly. 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-... ).

Some of those suggestions are pretty good, actually. I particularly like 7, 12, and 14.