On Friday, June 20, 2003, at 07:37 PM, Mark Brownell wrote:
unsigned long parray[]>From C & C++
0x243f6a88L, 0x85a308d3L, 0x13198a2eL, 0x03707344L, 0xa4093822L, 0x299f31d0L,
0x082efa98L, 0xec4e6c89L, 0x452821e6L, 0x38d01377L, 0xbe5466cfL, 0x34e90c6cL,
0xc0ac29b7L, 0xc97c50ddL, 0x3f84d5b5L, 0xb5470917L, 0x9216d5d9L, 0x8979fb1bL,
P_array From VB 5 version
H243F6A88, H85A308D3, H13198A2E, H3707344, HA4093822, H299F31D0, H82EFA98, HEC4E6C89,
H452821E6, H38D01377, HBE5466CF, H34E90C6C, HC0AC29B7, HC97C50DD, H3F84D5B5, HB5470917,
H9216D5D9, H8979FB1B
So signed numbers exist in the arrays of some versions in use.
I was thinking of the values rather than the variable types.
An signed variable that is greater than 32 bits can hold 32-bit unsigned numbers.
However, since Blowfish primitives are xor and addition and since most signed numbers are 2-complement it might not matter.
Even so, in Revolution once you bitAnd or bitXor, I would have expected unsigned values. I have only seen signed values come up in some uses of baseCovert().
If you are interested in speeding up your Blowfish, I'd look at binaryEncode and binaryDecode for the 4-char to/from 32-bit number. That 32-bit number will really get converted to 8-byte floating, but there is no loss; I believe it should behave just as you expect.
I would also use those for processing P-box hex tables.
I always get byte order mixed up.
Dar Scott
_______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
