Re: Re: [gui-dev] Re: Faster SHA1 and Tiger MessageDigestSPI's (version1.11)
Philippe VERDY <[email protected]> Fri, 2 Jul 2004 16:32:27 +0200 (CEST)
| Newsgroups | gmane.network.gnutella.limewire.gui.devel |
|---|---|
| Message-ID | <32031480.1088778747966.JavaMail.www@wwinf1003> |
> Message du 01/07/04 22:10
> > Can you give details about what is reported by the GNU Java compiler
> > as an "undefined" operation on some value?
>
> Uh no, not the GNU Java compiler (gcj). I'm talking about gcc...
>
> d += ((e << 5) | (e >>> 27)) + 0x5a827999 // K16
> + ((a & ((b = (b << 30) | (b >>> 2)) ^ c)) ^ c) // Ch(a,b,c)
> + (i00 = ((i00 ^= i02 ^ i08 ^ i13) << 1) | (i00 >>> 31)); // W16
>
> operation on `b' may be undefined
> operation on `i00' may be undefined
Thanks for correcting me, I thought you were speaking about the GNU compiler for Java.
Yes I know that in C and C++ the evaluation order is defined as much as precisely as in Java, so it's true that any subexpression that has a side effect on one of its variables is not guaranteed to be compiled and executed in the same order. For example the following C/C++ expressions has an undefined value for c:
int data[] = {1,2,3,4};
int *p = data;
int c = ((*p++)<<24) | ((*p++) <<16) | ((*p++)<<8) | (*p++);
because the side-effect of the incrementation of p is not guaranteed to be executed before the next indirection of p is executed...
So it's true that in C/C++, you need to decompose these expressions with side-effects which are only correct in Java, as documented and guaranteed in the Java specification.
_______________________________________________
gui-dev mailing list
[email protected]
http://www.limewire.org/mailman/listinfo/gui-dev