Pádraig Brady wrote: >> This minor point is becoming less important with time, as GCC >> > 4.5-or-later will eventually become ubiquitous. > Which might be an argument to take the simplest and most portable > approach from this dwindling case.
Hmm, well, a downside is that it would cause verify.h to include stdlib.h, which is a minor namespace hassle. Similarly, having verify.h depend on NDEBUG entangles verify.h with assert.h, another thing it's nicer to avoid. Since this particular business is for --enable-gcc-warnings, I'm not so much worried about the issues raised in the thread you mentioned, as assume (COND) is by design not-debuggable-by-gdb if COND is false -- that's how it works with newer GCC versions anyway, and it'd be strange if we went to some effort to make it work differently with older GCCs. I also thought of defining our own extern inline function that never returns, but that would mean we'd need a verify.c and this minor issue with older GCCs didn't seem to be worth that much hassle. I would have gladly removed the entire section in question (which would be simpler yet), since I don't use the old GCCs -- but when I did that in a related issue I got complaints from Emacs developers who use old GCC versions with --enable-gcc-warnings and so I left it in. Maybe we can remove it in 2016 or so. I could put in a comment to that effect, if you like.
