Forums before death by AOL, social media and spammers... "We can't have nice things"
|    sci.math.symbolic    |    Symbolic algebra discussion    |    10,432 messages    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
|    Message 8,773 of 10,432    |
|    James Kuyper to jacob navia    |
|    Re: Test for overflow    |
|    31 Mar 15 13:58:47    |
      XPost: comp.lang.c       From: jameskuyper@verizon.net              On 03/31/2015 01:48 PM, jacob navia wrote:       > Le 31/03/2015 19:41, James Kuyper a écrit :       >> I think so, so long as 'digit' is no wider than 'value'       >       > "Value" is an unsigned long long. To be able to overflow by adding a       > number smaller than 37, "value" *must* be bigger than 2^64 - 37.       >       > If an overflow occurs, at most the last 6 bits could be set, what is       > surely smaller than a number that is bigger thzn 2^64 - 37!!              The issue isn't the value of 'digit', but it's type. In the extremely       unlikely event that it was wider than unsigned long long (say,       int128_t), then 'value' would be converted to that wider type in both       places in the expression "value + digit < value". As a result, that       expression would detect overflow based upon the maximum value of the       wider type, producing false negatives if what you're really looking for       is overflow of the narrower type.       That's all based upon the possibility that 'digit' was wider than       'value', which I explicitly acknowledged was extremely implausible in       context. The purpose for which it's used could be served by unsigned       char, though unsigned int or unsigned long long would probably generate       faster code on many platforms. I just mentioned that possibility only       for the sake of completeness, since I had not seen any actual declarations.              --- SoupGate-Win32 v1.05        * Origin: you cannot sedate... all the things you hate (1:229/2)    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
(c) 1994, bbs@darkrealms.ca