Shachar Shemesh <shac...@shemesh.biz> writes: > On 13/04/14 05:39, Russ Allbery wrote:
>> One can make a good argument that such checks are exactly what you >> should be doing. > Then the answer is very simple. Write in Java. There are a lot of reasons other than the absolute fastest performance you can possibly muster to write something in C instead of Java. For example, if you're writing an Apache or PAM module, Java is not very useful, but that doesn't mean you need micro-optimized signed integer math or need to worry about the few instructions it takes to check parameters for whether they're NULL. There are some very experienced C programmers that make extensive use of preconditions and checks. For example, there was an article in Communications of the ACM within the past year (sadly, I don't remember exactly where and a quick search didn't help me out) that talked about a C coding style that aimed for defining checks for every non-trivial statement. With some macro assistance, the resulting code wasn't too ugly, and the result is rather appealing. It's been something I've been pondering experimenting with since reading that article. > I am not a compiler writer, so I have no actual data. I suspect your > common 20k line will yield about a thousand such warnings, the huge > majority of which there will be nothing for you to do about. > Also, it turns out gcc does have such an option. See > http://www.airs.com/blog/archives/120. -Wstrict-overflow will let you > know when the optimizer uses the assumption of no overflow to change > other code. Thanks for the pointer to that option! I'd missed that. I enabled -fstrict-overflow -Wstrict-overflow=5 -Werror in my standard utility library, which has about 13,000 lines of C, and got one additional warning, which was trivial to fix (and which was in a bit of code that has a rather bad smell and has been on my list to rewrite when I get a chance). So I'm not horribly impressed by your doomsday worries. :) That said, I believe that warning flag does not catch all possible overflows, just the ones where GCC happens to do an optimization. I use all sorts of warning flags, with -Werror, that I've seen other people claim are completely unworkable in practice, like -Wwrite-strings and -Wsign-compare. They're not. They just require care and attention and writing high-quality C code. >> Put a different way, the answer to your question is quite different if >> that function were instead: >> >> int compute_offset_into_network_packet( int a, int b ) >> { >> return a+b; >> } >> >> No? > In most cases, you will overflow the packet long before you overflow the > integer. Not if either a or b is coming from the network, which is the case I'm concerned about. You should do bounds-checking before using them to look at offsets in a packet. Tons and tons of security vulnerabilities have happened due to lack of that bounds-checking, or getting the check wrong. If there was a way for the compiler to check whether you've done that bounds-checking before you start doing math with those values, that would be very helpful. Obviously, that warning might not be appropriate for all code, but gcc has a rich pragmata system for handling that. > If that's the case, the compiler won't help you. That's the problem with C code in general: the compiler doesn't help you enough. Which is why I like seeing more warnings and smarter compilers that can, from the code, work out what invariants you've established and then warn you when you haven't checked for ones that may be important. clang, for example, does a great job of this (far better than gcc) at detecting variables that may be NULL at the point of use. There are, obviously, limits, since the C language semantically doesn't give either the author or the compiler a lot of help. But there are still opportunities for improvement. Ten years ago, I would have said that a lot of the diagnostics that clang provides were impossible in C because there just wasn't enough information available to the compiler. I was wrong. > Like I said before, I am not against the compilers warning about such > cases. I just think that these warnings need to be done very carefully, > or they become worse than useless. As such, if you see a case in which > you feel gcc (or clang, or whatever) should warn, by all means open a > bug for it. Just make sure you make it a "feature request" and not a > "security hole" severity. In other words, don't get mad merely because > the compiler author did not read your mind. I'll be sure to keep that in mind, since I've never reported a bug or discussed issues with compiler writers before. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87lhv9sy3y....@windlord.stanford.edu
