d-programming-language.org

[Steven Schveighoffer]

On Mon, 04 Jul 2011 17:10:04 -0400, bearophile <bearophileHUGS at lycos.com>  
wrote:

> Steven Schveighoffer:
>
>> Or, use a separate type which throws the errors if you wish.
>
> I have recently explained why this is not good enough, or even currently  
> impossible:
> http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=139950

You mean because people won't use them?  That's exactly my point.  I don't  
*want* to use them.  You do, so use them.  I might use it in cases where  
I'm nervous, especially when using decrementing for-loops.  But I don't  
think there would be a significant improvement in code quality if  
overflows are continually checked.  For one, it might be a *nuisance*  
error, i.e. overflow doesn't matter or was expected.  Two, it's a runtime  
error, so you must execute code in a certain way to see a failure.

Note that I've proposed a solution elsewhere to use c* (i.e. cint, clong,  
cuint, culong, etc.) to mean "checked" integral, then you can alias it to  
int or alias it to your struct type depending on debug flags you pass to  
dmd.  This should be a reasonable solution, I might actually use it in  
certain cases, if it's that easy.

>> 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.
>
> The idea is to add two switches to DMD that activate the integral  
> overflows (one for signed and one for signed and unsigned). If you  
> compile your code without those, the runtime tests will not happen.

See the solution I posted.  This can be done with a custom type and an  
alias.  It just shouldn't take over builtin types.

>> Besides, D is a systems language, and has no business doing checks
>> on every integer instruction.
>
> This argument doesn't hold, Delphi and Ada too are system languages.

I don't use them, and I'm less likely to now, knowing they do this.  Any  
systems language that does checks on every integer operation is going to  
give you a significant slowdown factor.

>> 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.
>
> Have you done benchmarks or are you refusing something just on a gut  
> feeling? I have done benchmarks of the overflow tests in C# and Delphi  
> and the slowdown we are seeing is not significantly worse than the  
> slowdown caused by array bound tests. And release mode is probably going  
> to be independent from the overflows switches. So you are allowed to  
> compile in non-release mode but without overflow tests.

Are you kidding?  An integer operation is a single instruction.  Testing  
for overflow requires another instruction.  Granted the test may be less  
than the operation, but it's going to slow things down.  We are not  
talking about outputting strings or computing some complex value.  Integer  
math is the bread-and-butter of cpus.  It's what they were made for, to  
compute things.  Herein lies the problem -- you are going to be slowing  
down instructions that take up a large chunk of the code.  It doesn't take  
benchmarking to see that without hardware support, testing all integer  
math instructions is going to cause significant slowdown (I'd say at least  
10%, probably more like 25%) in all code.

Comparing them to array bounds tests isn't exactly conclusive, because  
array bounds tests prevent a much more insidious bug -- memory  
corruption.  With overflow, you may have a subtle bug, but your code  
should still be sane (i.e. you can debug it).  With memory corruption, the  
code is not sane, you can't necessarily trust anything it says after the  
corruption occurs.

Typically with an overflow bug, I have bad behavior that immediately  
shows.  With memory corruption, the actual crash may occur long after the  
corruption occurred.

-Steve