On Thursday, July 2, 2015 at 2:32:21 PM UTC-4, [email protected] wrote: > > 0x12345678 is signed. > The rule for hexadecimal literals is int, unsigned int, long int, unsigned > long int, long long int, unsigned long long int according to 2.14.2 in the > Standard. > As 0x12345678 fits into an int it is an int and no implicit conversion > happens. >
I think what we are seeing (and what Marshall highlighted) is cryptographers are poor programmers at times. The original, reference implementation violated the C language because values like 0x89ABCFEF were too large to represent. If I could imbue one programming rule on the cryptographers, it would be to make everything unsigned. A close second would be to use int32_t, int64_t (and friends) for exact sizes, and stop relying on hazy implementation details on sizes of types. We still have other areas in the library where undefined behavior exists. To fix most of them, we need constant time rotate and reduce operations. But I have not had time to track them down. Or we need to drop into assembly language where the C rules don't constrain us. Jeff -- -- You received this message because you are subscribed to the "Crypto++ Users" Google Group. To unsubscribe, send an email to [email protected]. More information about Crypto++ and this group is available at http://www.cryptopp.com. --- You received this message because you are subscribed to the Google Groups "Crypto++ Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
