d-programming-language.org
Steven Schveighoffer
schveiguy at yahoo.com
Mon Jul 4 12:56:29 PDT 2011
On Mon, 04 Jul 2011 15:48:12 -0400, bearophile <bearophileHUGS at lycos.com>
wrote:
> Steven Schveighoffer:
>
>> To the point -- lots of existing D and C code uses the properties of
>> integer overflow. If integer overflow is assumed to be an error, then
>> that code is broken, even though the code *expects* overflow to occur,
>> and
>> in fact might *depend* on it occurring.
>
> In this case you wrap the code in something that allows it to overflow
> without errors, like:
>
> unsafe(overflows) {
> // code here
> }
Or, use a separate type which throws the errors if you wish. I don't want
runtime errors thrown in code that I didn't intend to throw. most of the
time, overflows will not occur, so I don't want to go through all my code
and have to throw these decorations up where I know it's safe. Besides, D
is a systems language, and has no business doing checks on every integer
instruction. Yes non-relase mode is slower, but we are probably talking
about a very significant slowdown here. A lot of integer math happens in
D.
I think a much more effective fix for the language would be to make slice
length a signed type. Then you simply eliminate 99% of integer overflows
(it's very rare that a signed integer overflows, but not so unlikely that
an unsigned one does).
At this point, any change to the semantics of the builtin types will be
extremely disruptive. We should focus our efforts elsewhere.
-Steve
More information about the Digitalmars-d
mailing list