Michael Hudson <[EMAIL PROTECTED]> writes: > "Raymond Hettinger" <[EMAIL PROTECTED]> writes: > >> [Raymond Hettinger] >>> > This patch should be reverted or fixed so that the Py2.5 build works >>> > again. >>> > >>> > It contains a disasterous search and replace error that prevents it >> from >>> > compiling. Hence, it couldn't have passed the test suite before >> being >>> > checked in. >> >> [Michael Hudson] >>> It works for me, on OS X. Passes the test suite, even. I presume >>> you're on Windows of some kind? >> >> >> Here's an excerpt from the check-in note for sha512module.c: >> >> >> RND(S[0],S[1],S[2],S[3],S[4],S[5],S[6],S[7],0,0x428a2f98d728ae22ULL); >> >> RND(S[7],S[0],S[1],S[2],S[3],S[4],S[5],S[6],1,0x7137449123ef65cdULL); >> >> RND(S[6],S[7],S[0],S[1],S[2],S[3],S[4],S[5],2,0xb5c0fbcfec4d3b2fULL); >> >> RND(S[5],S[6],S[7],S[0],S[1],S[2],S[3],S[4],3,0xe9b5dba58189dbbcULL); >> >> RND(S[4],S[5],S[6],S[7],S[0],S[1],S[2],S[3],4,0x3956c25bf348b538ULL); >> >> Perhaps OS X has some sort of Steve Jobs special constant suffix "ULL" >> that Mr. Gates and the ANSI C folks have yet to accept ;-) > > It's an C99 unsigned long long literal, AFAICT (p70 of the PDF I found > lying around somewhere...), so I think it's just Bill who's behind. > However, Python doesn't require C99, so it's pretty dodgy code by our > standards. > > Hmm. You have PY_LONG_LONG #define-d, right? Does VC++ 6 (that's > what you use, right?) support any kind of long long literal?
The suffix seems to be 'ui64'. From vc6 limits.h: #if _INTEGRAL_MAX_BITS >= 64 /* minimum signed 64 bit value */ #define _I64_MIN (-9223372036854775807i64 - 1) /* maximum signed 64 bit value */ #define _I64_MAX 9223372036854775807i64 /* maximum unsigned 64 bit value */ #define _UI64_MAX 0xffffffffffffffffui64 #endif Thomas _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
