From: Greg Colvin (Gregory.Colvin_at_[hidden])
Date: 2002-08-22 15:09:59
At 12:38 PM 8/22/2002, David Bergman wrote:
>I assume the encryption routine implementers are kind of interested in
>getting "correct" results...
Yes. When I've done it I've counted on correct unsigned results, using
masks and shifting to control the modulus and extract high-order results.
On most machines compilers can optimize away the masks and shifting when
they are aligned on register boundaries. So you get portable, correct,
and fast code if you and the compiler do your job.
>And, obviously, signed integer arithmetics cannot take place in a modulo
>ring, since such a ring does not include negative numbers...
>But, that is not a loop-hole for using double-precision in interims,
>since the positive numbers of "int" (just to take an integral example)
>have to be a subset of "unsigned int", so see, you still cannot maneuver
>out of the modulo ring...
>I.e., it is still invalid of an implementation to do the trick you
No, it is perfectly valid. If the product of two ints overflows all
bets are off.
>[mailto:boost-bounces_at_[hidden]] On Behalf Of Bill Seymour
>Sent: Thursday, August 22, 2002 1:55 PM
>Subject: [boost] Re: (boost) Re: A pure C/C++ question
>Victor A. Wagner wrote:
>> I'm one of those weirdos that thinks that "correct" is
>> a lot more important than "fast".
>Perhaps in your application domain. Folk who write,
>e.g., encryption routines would disagree. They need
>arithmetic to be fast and repeatable (gets the same
>answer every time). Whether it gets the "correct"
>answer is totally irrelevant.
>David Bergman wrote:
>> [Integer] arithmetic is supposed to be module 2^n, ...
>No, just unsigned integer arithmetic. As others have
>already said, signed integer overflow yields undefined behavior. That
>includes, but is not limited to, wrapping modulo 2^n as if it were
>unsigned (MSVC and others), INT_MAX + 1 == 1 (Borland, IIRC), hardware
>traps (Unisys, Cray, IIRC), ...
>Unsubscribe & other changes:
>Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk