> > Manu: > > > Also, contrary to his claim, I find that wrapping is usually what I > > DO want in this case.. > > It's super rare that I write any code that pushes the limits of an int > > (unless we're talking 8-16 bit, see my range+saturation comment before), > > and when I do write code that pushes the range of an int, I can't think > of > > a time when I've not wanted to wrap as expected. > > The code you usually write seems rather unusual. I have kind of the > opposite situations. > > But first of all, "trapping" ints are needed to avoid bugs in normal code. > Some bugs are shown here: > http://embed.cs.utah.edu/ioc/
I write C/C++ systems/embedded/games code (not a small industry by any measure), and I'm looking to D as a successor.. I'm NOT interested in D as a replacement for C# (or Java/etc), those languages already exist, are well supported, and I'm happy with them for their purpose. I realise I seem to be one of the odd ones out on this forum currently, hence I like to throw my 2c in from time to time :) .. but I don't believe I'm alone.. the rest of the gamedev community will find D soon enough if the language gets it right... I did see some examples of the common overflow bugs via links in your OP, but I just have never run into those problems myself.. A couple of them depended on an actual bug in your code. for instance this one: *result = result * 10 + cursor - '0';* Should have been: *result * 10 + (cursor - '0')* This isn't a legitimate runtime error, it's compile time/logic bug. Perhaps a warning should be generated at compile time if the logic can be deduced... (probably impossible) If you're suggesting the reason for trapping overflow's is specifically to CATCH bugs like this, then maybe make is a compiler flag when building a debug binary? (ie. assert on integer overflow).