primitive value overflow

[1100110]

On 05/16/2013 04:17 PM, Mr. Anonymous wrote:
> On Thursday, 16 May 2013 at 21:04:38 UTC, Jonathan M Davis wrote:
>> On Thursday, May 16, 2013 22:42:23 luka8088 wrote:
>>> I agree that it is exactly the same as checking if (text1.length >
>>> text2.length). And I don't think that this is an issues if you are aware
>>> of the fact that you are working with unsigned values. But in the code
>>> that I wrote there was no mentioning of unsigned so the possibility of
>>> that kind of issue never came to mind until I actually printed the
>>> values. And that is what I wanted to emphasize.
>>
>> Well, I'm not sure what can be done about that. length is size_t,
>> which is the
>> unsigned integral value which matches the architecture (uint for
>> 32-bit and
>> ulong for 64-bit). AFAIK, the documentation is clear on this (though I
>> haven't
>> read it recently). If it's not, then it should be made clearer, but using
>> size_t for length is pervasive in D as it is in C++, and if you know the
>> standard types, you know what size_t is.
>>
>> As for overflow checking, it's come up quite a few times, and Walter is
>> completely against it. The hardware doesn't support it, and it would
>> definitely
>> be slow if it were added. The standard way to handle that if you want
>> it is to
>> create user-defined integral type which does the checks (though that
>> obviously
>> won't help you when you can't control the types that you're dealing
>> with). But
>> if you want to add checks in your code, you can always create a wrapper
>> function for doing the subtraction. And if you wanted the checks to
>> only be
>> there in non-release mode, then you could even put the checks in a
>> version(assert) block. So, you can add checks if you want them, but
>> there's
>> pretty much no way that how unsigned or overflow are handled in the
>> language
>> is going to change.
>>
>> - Jonathan M Davis
> 
> I agree with Walter if we're talking about production code, but I think
> it could be very helpful for debug builds.
> 
> P.S.
>> The hardware doesn't support it
> That's not completely true.
> e.g. x86, while it doesn't throw an exception on an overflow, it does
> set a flag, which could be relatively cheaply checked.


Perhaps a compiler flag would be nice, can't really argue performance if
it's explicitly chosen.  Like -profile or -cov.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 900 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20130516/130adebf/attachment-0001.pgp>