I've been a C developer most of my professional life, and I find any discussion about the 'right way to write C' to be worth the effort, usually, because it mea

I've been a C developer most of my professional life, and I find any discussion about the 'right way to write C' to be worth the effort, usually, because it means either more C coders will be produced with always-interesting results, or the kinds of developers who shouldn't be C coders in the first place will wander off and invent something new and shiny to play with instead. Both conditions are valid. C is such a thorny language precisely because of the trouble you can get in, and as such it does require a degree of competence that your average IDE-wielding neophytes are not willing to conjure up in all their free time. Digging into the details is the only way to succeed with C. For me the breakthrough came during my SIL-4 professional period (safety-integrity level 4, life-critical systems..) experience, wherein I learned the value of testing, and always testing, and strict requirements with standardized rules. I also learned the value of code-coverage tools and why you use them to increase the 'safe-ness' of your code. And yes, your issue with undefined behaviour, means of course you should never rely on your compiler/IDE to tell you what is going on, and should know by inspection, always! In the end though, C still has a lot of uses and applications left to be written - its not going away any time soon - and so as long as a group of people are willing to agree to what they are doing with the C code base, good stuff gets built. (PS, Lua for the win!)