1

Integer arithmetics in C# can be set to throw an OverflowException using checked, as in the following example: 

int a = foo();
int b = bar()
int result = checked(a * b); // Will result in OverflowException if this overflows

I'm currently getting more into C programming and just found a bug that was due to an integer overflow - which would have been much more easier to find with something like checked - and I ask myself: Why is nothing similar implemented in C? Can someone explain it to me or point me out (some standard reference, etc.) where it is stated why such a construct is not part of the C language?

Or am I completely wrong and there is some built-in functionality to check for (integer) overflows on arithmetic operations?

Markus Weninger
  • 11,931
  • 7
  • 64
  • 137
  • 3
    What is a "runtime exception" in C? – e0k Feb 13 '16 at 20:34
  • I changed it to [OverflowException](http://msdn.microsoft.com/en-us/library/system.overflowexception%28v=vs.110%29.aspx) to make it more clear. – Markus Weninger Feb 13 '16 at 20:36
  • 3
    You'll probably not be able to find documentation on why all the possible features that could be in in a language arn't there. – nos Feb 13 '16 at 20:37
  • 2
    GCC offers quite a few (see https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins.html), but the real reason is because they're not part of the C language - as far as that's a "reason" for not having something. There are lot of things C doesn't have. – Andrew Henle Feb 13 '16 at 20:38
  • 4
    *Can someone explain it to me or point me out (some standard reference, etc.) where it is stated why such a construct is not part of the C language?* -- C also doesn't have templates, polymorphism, reflection, actual string types, etc. etc. Do you want to have a document explaining all of the possible missing "features"? If it did, it would be thousands of pages long, and still wouldn't be complete. – PaulMcKenzie Feb 13 '16 at 20:40
  • I saw that question, and I read the answers, yet they all just did not answer my question why all of these features are mostly compiler specific are are not part of the C standard. But you are right, finding out why something _is not_ in a standard will be hard. I just thought that probably it is stated somewhere why the decission was made to not include it or that there is some technical reason to it. – Markus Weninger Feb 13 '16 at 20:40
  • 3
    With that sentence, you're assuming a decision was ever made. Why do you think the committee even thought about this option in the first place and *decided* to leave it out? – Alex Celeste Feb 13 '16 at 20:41
  • 1
    @MarkusWeninger Note -- C doesn't even have array bounds checking, so expecting it have some other built-in runtime checks would be far-fetched. Heck it doesn't even have exceptions -- basically, you are in total control, with little to no runtime help on anything. – PaulMcKenzie Feb 13 '16 at 20:45
  • 2
    There are no "exceptions" in C, and no "try/catch" mechanism like in C++ and other languages. It is more of a "bare metal" way of writing programs. If you want to check for something, you do it yourself. This may seem harsh if you're used to some other language that checks every little thing for you, but the benefit is control. If you don't need to check something, you can save time by not doing it. With more power comes more responsibility. – e0k Feb 13 '16 at 20:47
  • @Leushenko: Sorry, I didn't want to sound like that. I just thought that there _probably_ has been such a decision, and if so, someone could tell me why. But you are right, and such a decission doesn't ever have had to be made. "With more power comes more responsibility" are true words. I think I just have to get my head more into "the C way of thinking". Thank you all for explaining things to me. – Markus Weninger Feb 13 '16 at 20:52
  • 4
    C was designed before all of the languages started hand-holding their developers, back when you actually had to have real skills to write code. You know - back before VB started letting everyone easily write (bad) code and get away with it. :-) – Ken White Feb 13 '16 at 21:07
  • @KenWhite: I know what you mean, and I really like that in C its all in your hands. Yet if you come from modern, memory-managed languages like C# or Java (sorry that i wasn't born back in the time where you "had to have real skills to write code", I started programming by learning those languages at school :P) you are not used to all of this. Yet I think it's not the skill I'm missing, its all about the pratice i need to get. And that's why I'm asking - to learning new things and to get my hands dirty by trying new things :) – Markus Weninger Feb 13 '16 at 21:14
  • 1
    The point I was trying to make is that C didn't implement a lot of the things that languages did now because a lot of them didn't exist at the time, or because they weren't considered necessary for "real programmers" (those that used C). In fact, at the time C was popular, there were a lot of developers around who thought it was too high level and that real programmers didn't use it - they wrote assembly code instead. You can't reasonably ask for documentation about why a committee didn't choose to implement something that didn't exist at the time. C != C# (or even C++). – Ken White Feb 13 '16 at 21:19
  • @KenWhite: Many earlier languages had integer overflow trapping. The present state of C represents the worst of all possible worlds if one is designing applications which have *any* sort of behavioral requirement on inputs which could cause overflow, since C lacks the ability to express overflow-avoidance code in a way that would grant compilers the same level of flexibility they would have if the language semantics were defined slightly better such that programmers with loose requirements wouldn't *have* to write overflow avoidance code. For example, if a function is... – supercat Feb 19 '16 at 05:51
  • ...used to identify "potentially interesting" objects, no genuinely-interesting objects will cause overflow, and overflows won't be terribly common with uninteresting objects, the most efficient approach historically would have been to let overflows happen and cause some uninteresting items to be classified as "possibly interesting". If "potentially interesting" items are subjected to more expensive tests, having overflows cause some items to be subjected to such tests may impose some performance cost, but if that happens rarely that cost may still be well below... – supercat Feb 19 '16 at 05:59
  • ...the cost of overflow-avoidance code. To be sure, if C had checked integer types in addition to unchecked types, those could greatly improve the performance of code which is required never to produce seemingly-valid-but-wrong answers, especially if the semantics were such that calculations which overflowed were allowed to silently yield *correct* answers. – supercat Feb 19 '16 at 06:01
  • 1
    @MarkusWeninger: A better question might be "What difficulties would there be in adding something like "checked" regions to C"? There are a number of issues which you're probably not aware of, such as the effects of out-of-order execution. On the other had, I would suggest that one of the big reasons that C compilers have often lacked options for overflow checking is that historically a lot of code relied upon wrapping overflow behavior even for signed values, and adding overflow checking globally would break such code. What's especially ironic about that is that... – supercat Feb 19 '16 at 06:07
  • ...modern compilers by design make it impossible to define *any* limits to the consequences of overflow, even on platforms which use a uniform size of register for all calculations and have no hardware overflow traps. – supercat Feb 19 '16 at 06:08

0 Answers0