RE: [boost] Re: (boost) Re: A pure C/C++ question

From: David Bergman (davidb_at_[hidden])
Date: 2002-08-22 19:21:42

Don't you love that "forget everything" attitude of C++. Just put a 5/0
ANYWHERE in the code, and there are NO REQUIREMENTS whatsoever on
anything. Whatever the behavior, it is still a compliant C++
implementation...

I think they really stretched the "compliance" semantics a bit too far.

Is it that lenient attitude of The International Standard you are
referring to? If it is, then we can claim nothing, every imaginable
behavior is totally alright. If not, we still require that the
subexpression "a*b" has a type, and in that case I want to know which
type it has, and what limits are put on that type.

You see, even though we can choose, as implementers to add overflow
semantics, an "int" has to be an "int" everywhere, with its constraints
of the positive members being contained in "unsigned int".

/David

-----Original Message-----
From: boost-bounces_at_[hidden]
[mailto:boost-bounces_at_[hidden]] On Behalf Of Greg Colvin
Sent: Thursday, August 22, 2002 4:10 PM
To: boost_at_[hidden]
Subject: RE: [boost] Re: (boost) Re: A pure C/C++ question

At 12:38 PM 8/22/2002, David Bergman wrote:
>Bill,
>
>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 
>described.

No, it is perfectly valid.  If the product of two ints overflows all
bets are off.

>/David
>
>-----Original Message-----
>From: boost-bounces_at_[hidden] 
>[mailto:boost-bounces_at_[hidden]] On Behalf Of Bill Seymour
>Sent: Thursday, August 22, 2002 1:55 PM
>To: boost_at_[hidden]
>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), ...
>
>--Bill Seymour
>_______________________________________________
>Unsubscribe & other changes: 
>http://lists.boost.org/mailman/listinfo.cgi/boost
>
>_______________________________________________
>Unsubscribe & other changes: 
>http://lists.boost.org/mailman/listinfo.cgi/boost

_______________________________________________
Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost