Students uncover dozens of Unix software flaws (News.com)

Posted Dec 17, 2004 10:58 UTC (Fri) by sdalley (subscriber, #18550) [Link]

Yes, one could use exactly the same argument as Drepper's to say that safety razors are completely nonsense, they don't increase safety, they only allow sloppy shavers get by without having to learn the use of an old-style cutthroat.

The track record of OpenBSD, however, speaks for itself.

Posted Dec 17, 2004 18:17 UTC (Fri) by JoeBuck (subscriber, #2330) [Link]

The strl* functions are not magic, though they can be useful in getting rid of one class of error (and replacing it with another, less severe, class of error: the silent truncation of long lines).

Reading a line into a fixed-sized buffer is the problem, and use of strl* functions to get rid of the buffer overrun is only a band-aid. You may think that you can assume that no valid line will be more than N characters, and later on break when you get N+1 characters. You can get subtle bugs because strings are truncated to different lengths in different places.

Read lines into dynamically-sized buffers instead, e.g. std::string for C++ programmers, appropriate library for C programmers. The GNU Readline library, for example, does not impose arbitrary limits on string length (as long as you have virtual memory).

Posted Dec 18, 2004 5:53 UTC (Sat) by ncm (subscriber, #165) [Link]

Ulrich is right, as far as he goes.

However, by not providing bindings for functions with those names, he encourages sloppy programmers porting programs that call them to grab the BSD implementation and add it in.

If Glibc were to implement strlcpy etc. but, instead of returning a value to be checked, simply log an error and call abort(), then the bugs would have attention called to them. They could not just silently fail no matter how sloppily coded. Of course, sloppy code shouldn't be run at all (there are a lot more ways to fail than strcpy!). A program that is always aborting is less likely to be run. Problem solved.