17 ms·

You can't overstate the importance of a specification. It is the most loathed thing to write, like unit tests, but in the end is essential. I think the OP roman

You can't overstate the importance of a specification. It is the most loathed thing to write, like unit tests, but in the end is essential. I think the OP romanticizes a bit: K&R C had a spec, a very very very loose spec. It took ANSI a decade to put some meat on it. Early C compilers weren't much help: Sparc had SystemV and AIX had POSIX which are OS specs but still defined C behavior in their compilers, and it made life so much easier in the early 90's when they converged on Gnu. My favorite part of the article is the footnote. We really need to stop referring to C/C++ as "roughly the same" because they are so so so radically different.

wglb 8y ago
K&R C had no formal spec. It wasn't until 10 years after its invention that it did, and that was after a lot of real-world experience. I would argue that early specifications don't work out very well. In fact, they are often problematic. One example is that standard ANSI C had a proposal for a while that included an Alias keyword. This was such a bad idea, that Dennis Ritchie showed up to the meeting personally to help kill it. Standards committees are not usually staffed with practitioners, who are busy developing the language and are quite expert in nuance, feasibility, and utility. Attendees to standards committee meetings are almost always not. And reality does meet the standardization expectations quite frequently. Look at the number of "undefined" or "implementation choices" in C alone. Therein lie careers for security folks.