Null References, the Billion Dollar Mistake
jonr writes "'I call it my billion-dollar mistake. It was the invention of the null reference in 1965. At that time, I was designing the first comprehensive type system for references in an object oriented language (ALGOL W). My goal was to ensure that all use of references should be absolutely safe, with checking performed automatically by the compiler. But I couldn't resist the temptation to put in a null reference, simply because it was so easy to implement. This has led to innumerable errors, vulnerabilities, and system crashes, which have probably caused a billion dollars of pain and damage in the last forty years. In recent years, a number of program analysers like PREfix and PREfast in Microsoft have been used to check references, and give warnings if there is a risk they may be non-null. More recent programming languages like Spec# have introduced declarations for non-null references. This is the solution, which I rejected in 1965.' This is an abstract from Tony Hoare Presentation on QCon. I'm raised on C-style programming languages, and have always used null pointers/references, but I am having trouble of grokking null-reference free language. Is there a good reading out there that explains this?"
Null-terminated strings. The bane of modern computing.
Maybe I'm feeding a troll, but what else would you terminate it with without using something the string may contain? Keep in mind that null-terminated strings were, err, "invented" around the time ASCII was really the only fully widespread character standard, and something was needed to mark the end of a string for detection by software.
The mistakes you speak of are made by programmers that don't know how to securely utilize this in certain environments. Mainly in buffers, but recall the lkml thread about the license macro in kernel modules being abused with '\0'.
I've written plenty of assembly for a variety of processor architectures, and almost all OS's I've dealt with at the assembly level, including my own, have used 0/NULL as the string terminator (higher-level languages just "hide" this). I've also seen and debugged many overflow problems, but much of this has become a thing of the past due to GCC and other compilers having built in stack smashing/overflow protection, implemented by IBM's ProPolice in GCC.
I know fully what your comment meant, and yes - the way the strings are terminated/accounted for length-wise vary from implementation (e.g. Pascal vs. C), but the bounds checking is where most either don't enforce enough, or leave plenty of room for the programmer to "shoot themselves in the foot", as Bjarne Stroustrup said.
And while I like the idea of immutable strings in some languages, sometimes it tends to get in the way of solving some problems, at least from a lower-level perspective. That, or I'm just way too set in my ways with C and other unchecked languages but who cares, as long as I check my bounds which seems to be a huge problem for many these days.