4 ms·
I wonder when this was written. The earliest reference I found was June 1993 in an AUUG (Australian Unix Users Group) newsletter. http://books.google.com/books?
by jws 16y ago
I wonder when this was written. The earliest reference I found was June 1993 in an AUUG (Australian Unix Users Group) newsletter. http://books.google.com/books?id=lbsmK77EVU4C&lpg=PA1&pg=PA36#v=onepage&q&f=false http://books.google.com/books?id=lbsmK77EVU4C&lpg=PA1...
1) run lint: Not anymore. But then I'm a -Wall -Werr kind of guy and I visit Clang.
2) don't follow NULL: Well, obviously.
3) cast function arguments to the expected type: Not important now that the types are in the declarations. But if you don't force that, then yes. Got that right. Just as people got complacent with 32bit data and address, BANG!
4) declare return types for functions: That insanity has passed from practice.
5) check bounds: Yep, still causing exploits today.
6) check error codes: Yep, and triples is about right for library/system call intensive code. But the first time fclose() returns an error and you catch it you will be happy.
7) don't re-implement the library: Beating a modern C library is hard. But: if you have a special case, you can still get a significant gain by exploiting that, after you have profiled and know you aren't engaging in petty puffery. (It should be mentioned that the author is the Henry Spencer that wrote and distributed a regex library back in the days of ftp.)
8) use K&R brace styles: I care so little for brace styles I can't tell you which is K&R after writing hundreds of thousands of lines of C code.
9) external symbols must be unique in the first 6 characters: Ha ha! Good riddance SCO, the last system I met where that was an issue (in ar libraries only I think.)
10) all the world's a vax: s/VAX/x86/ e.g. I keep a PPC (byte order) and an ARM (char is unsigned) just to keep me honest on this.
- JoachimSchipper 16y agoTwo additions: 1) -Wall -Werr does not note type conversions (indeed, it could not, because they are necessary - just dangerous. -1 < 0U is usually not true!) 3) Casting is very much necessary with function taking a variable number of arguments. But yes, modern tools and C90/C99 help a lot.
- nitrogen 16y agogcc -Wall does warn about comparison between signed and unsigned types, as well as comparisons that are always true/false due to limited type range.
- JoachimSchipper 16y agoBut you can't really enable those warnings if you want to use -Werr, right? And I've always found the "always true/false due to limited range of data type" to be counterproductive. Something like int i; ... assert(i <= SSIZE_MAX); f(i); can make sense, but will cause gcc to complain if int and ssize_t happen to be the same size.
- JoachimSchipper 16y agoOf course, you should use ssize_t i and i <= INT_MAX...
- nitrogen 16y agoThere are ways of fixing the warnings so you can use -Werr. For signed/unsigned, just change the type of one side of the comparison, or cast to whichever type is most correct for the comparison while manually making sure that you won't have any range issues. For your limited range example, you could probably use the preprocessor: ssize_t i; #if SSIZE_MAX != INT_MAX assert(i <= INT_MAX); #endif /* SSIZE_MAX != INT_MAX */ f(i);
- oiu87y6trtyuiop 16y ago9 - yeah though thy compiler hath longer variables beware the fashionistas who call their variables. com.sun.java.variable.main.graphics.coordinates.point.x and com.sun.java.variable.main.graphics.coordinates.point.y
- codefisher 16y agoI agree with you on 8) I don't see why it matters so much what style of braces are used as long as the block of code and I currently looking as it consistent. If future developers object that badly, there is also many many auto formatters out their to fix it. the article is clearly rather dated, and a number of the points (as jws notes) are rather irrelevant now.