3 ms·
The most dramatic example is the INT_MIN/-1 case, since that causes an outright crash. For example, Windows has the ScaleWindowExtEx function, which scales a w
by ridiculous_fish 11y ago
The most dramatic example is the INT_MIN/-1 case, since that causes an outright crash.
For example, Windows has the ScaleWindowExtEx function, which scales a window by some rational number, expressed as the ratio of two ints. Using signed arithmetic is already suspicious: what does it mean to scale a window by a negative fraction? But of course they forgot about the INT_MIN/-1 case, and the result is a BSOD. http://sysmagazine.com/posts/179543/ http://sysmagazine.com/posts/179543/
http://kqueue.org/blog/2012/12/31/idiv-dos/ http://kqueue.org/blog/2012/12/31/idiv-dos/ has some others. Fun stuff.
- SamReidHughes 11y agoEvery single one of those cases involve integers that necessarily must be signed, in order for the interface to work. They're implementing an interpreted language having signed integers, or in the one other case, with ScaleWindowExtEx, it manipulates values that are signed, and that have meaning when negative. The one place I saw an INT_MIN / -1 bug (in code review, iirc) was also for an interpreted language implementing a modulo operator. These are bugs with signed integer usage, but they're not bugs caused by a decision to use signed integers, because in these cases, there was no choice. They aren't representative of what you see when you do have a choice, say, using signed integers for array indices and sizes. The question of what bugs you actually see was meant to be a personal one, not one of some dramatic bug you've read about on the internet. The answer of which is the better choice is defined by how much damage is caused by one choice versus the other, and you get that answer by noting how frequently you get bugs in practice as a result of such decisions. (Not that thought experiments and imagination no place, but this is clearly a question for which you can talk yourself into any direction.) For example, I've never had problems with C/C++ undefined behavior of signed integer overflow, while you're spending a lot of time talking about that. I have seen bugs caused by unsigned and signed integer usage that fit into other categories, though.
- ridiculous_fish 11y agoThe ScaleWindowExtEx example certainly has no legitimate reason to accept signed ints. Personally, the bug I introduce most often with signed ints is a failure to range-check for negative values, e.g.: void *get(int idx) { assert(idx <= arr.size(); return arr[idx]; }
- SamReidHughes 11y agoThe "legitimate reason" is that it's scaling a signed value, that has meaning when negative. > void *get(int idx) { assert(idx <= arr.size(); return arr[idx]; } You got problems there even if idx and arr.size() are unsigned.
- deleted 11y ago[deleted]
- kazinator 11y agoWithout signed integers, the scaling function will turn arguments like (-4, -3) to garbage. In order to disallow negatives, you need signed arguments, or else to reduce the range. (Say the numerator and denominator cannot exceed 255 or whatever). Otherwise the function has no way of knowing whether argument values (UINT_MAX-3, UINT_MAX-2) are a mistaken aliasing of -4, -3 or deliberately chosen positive values.
- ridiculous_fish 11y agoGarbage in, garbage out, as they say. For all we know the ScaleWindowExtEx did have a domain check that disallowed negatives, but it put it after the division.
- SamReidHughes 11y agoIt permits negatives! SetWindowExtEx permits negatives!