TR 24731 and Safety
The functions in TR 24731 are useful in some situations. They're not the ultimate answer to the problem of buffer overruns. As always, careful design, thorough testing, and code reviews are the steps needed to write fast, robust, and correct applications.
Notes
- [1] Officially, that's ISO/IEC TR 24731, "Information Technnology—Programming languages, their environments and system software interfaces—Specification for Safer, More Secure C Library Functions." It's still being worked on, so it's a draft and not a final document. You can get a copy at http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1135.pdf.
- [2] It also provides functions that, unlike their Standard C counterparts, can be called from multiple threads without worrying about one call overwriting static data in use by another thread. But that's a subject for a different column.
- [3] When Borland was working on its first compiler that supported Windows, we had a mysterious crash in one of the programming examples from Microsoft's Windows SDK. The program ran fine with Microsoft's compiler and library, and crashed with ours. Since our compiler and library were incomplete, we naturally focused on them. But it turned out that the problem was in the example, which had a buffer overrun.
- Borland's compiler arranged auto variables in a different order than Microsoft's did, turning this symptom-free overrun into a program crash.
- [4] Commodore 64 programmers should recognize this technique. It's how we did assembly language programming from BASIC—stuff opcodes into an array and jump. Tedious, but it worked.
- [5] But intermediate functions shouldn't have an assert to check the length of the string. There's nothing to be gained by testing there, since the function that does the copy will make the debugging check.
DDJ
