[rc5] Alpha displays strange keys

Sanford Olson sanford at msn.fullfeed.com
Sat Jul 19 02:13:21 EDT 1997


At 02:15 AM 7/19/97 +0200, you wrote:
>
>
>The Alpha (rc5v2b2-decunix32-alpha-ev4) client sometimes displays strange
>values for the keys, i.e. it adds 32bits worth of FF before the second
>part ! It does this for some keys and not for the others. It looks like a
>32/64 bits int problem. Here is an extract of my log file: 
>
>[07/18/97 01:23:13 GMT] Block: 41B4CF:00000000 being processed
>[07/18/97 01:23:13 GMT] 8 Blocks remain in file buff-in.rc5
>.....10%.....20%.....30%.....40%.....50%.....60%.....70%.....80%.....90%....
>[07/18/97 02:14:02 GMT] Completed block 41B4CF:00000000 (268435456 keys)
>                        00:50:49.16 - [88035.81 keys/sec]
>[07/18/97 02:14:02 GMT] Block: 41B4CE:FFFFFFFFE0000000 being processed
>[07/18/97 02:14:02 GMT] 7 Blocks remain in file buff-in.rc5
>.....10%.....20%.....30%.....40%.....50%.....60%.....70%.....80%.....90%....
>-- 
>Francois Gouget
>fgouget at club-internet.fr                http://www.mygale.org/~fgouget/


I've done some programming (not for rc5 stuff) and my guess is...  the
Alpha is 64-bit, so all "int" types would be promoted to 64-bits when
passed as parameters to the C/C++ "fprintf" function.  However, the
"fprintf" function seems not to be using the given field width when writing
negative hex numbers.  Perhaps, it sees the number as a unsigned hex
number.  This could be a bug in the "fprintf" function, in the format
string for the "fprintf" function, or in the actual types that are used to
hold the keys (signed vs. unsigned).  These bugs don't show up when the
code is compiled on a 32-bit compiler.  I saw a lot of these type issues
when porting code from a 16-bit environment to 32 bits.

At any rate, I'm sure that it is just a cosmetic bug.

- Sanford Olson


----
To unsubscribe, send email to majordomo at llamas.net with 'unsubscribe rc5' in the body.



More information about the rc5 mailing list