home bbs files messages ]

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