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