> I haven't witnessed any problems like you describe, so maybe the OS I
> am using is well behaved.
"maybe" is not acceptable answer:-) What is it? I *assumed* it was
Linux, but gcc -dumpspecs predefines __CELLOS_LV2__ which doesn't sound
like Linux... The macro doesn't seem to be present in stock
uot; you requested is attached.
-Ben
-Original Message-
From: Andy Polyakov via RT [mailto:r...@openssl.org]
Sent: Saturday, September 12, 2009 9:21 AM
To: Ben Nason
Cc: openssl-dev@openssl.org
Subject: [Fwd: Re: [openssl.org #1998] [PATCH] SHA512 ROTR macro fix for
PowerPC using LP32 m
uot; you requested is attached.
-Ben
-Original Message-
From: Andy Polyakov via RT [mailto:r...@openssl.org]
Sent: Saturday, September 12, 2009 9:21 AM
To: Ben Nason
Cc: openssl-dev@openssl.org
Subject: [Fwd: Re: [openssl.org #1998] [PATCH] SHA512 ROTR macro fix for
PowerPC using LP32 m
Oops. Should have replied to r...@openssl.org. Sorry about duplicate. A.
Original Message
Subject: Re: [openssl.org #1998] [PATCH] SHA512 ROTR macro fix for
PowerPC using LP32 model
Date: Sat, 12 Sep 2009 18:57:58 +0200
From: Andy Polyakov
Reply-To: openssl-dev@openssl.org
To
> I just ran into a bug where SHA384/512 were not being calculated
> correctly on the Cell processor. I tracked it down to the definition of
> the ROTR macro, which is assuming a 64 bit long, but in this case the
> compiler is using the LP32 model so long is 32 bits and the values were
> being trun
Hi,
I am new to the list, so apologies if I fail to follow any of the ground
rules.
I just ran into a bug where SHA384/512 were not being calculated
correctly on the Cell processor. I tracked it down to the definition of
the ROTR macro, which is assuming a 64 bit long, but in this case the
compil
