On 12/11/15 17:41, Michael Wojcik wrote: >> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf >> Of Andy Polyakov >> Sent: Friday, December 11, 2015 10:07 >> To: openssl-users at openssl.org >> Subject: Re: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in >> OpenSSL 1.0.2d >> >>>> static inline unsigned int constant_time_msb(unsigned int a) { >>>> - *return 0 - (a >> (sizeof(a) * 8 - 1));* >>>> + return (((unsigned)((int)(a) >> (sizeof(int) * 8 - 1)))); >>>> } >>> >>> >>> ... Both versions >>> look reasonable to me (ignoring the hardcoded 8 - implying a char is 8 >>> bits). >> >> Hardcoded 8 is not reference to char C type, but to units in which >> sizeof(variable) is measured. For example when we say ILP32 or LP64, >> what do we mean and what role does 8 play in the drama? > > The distinction you're drawing is meaningless. Right, I've let practical myself talk too soon, sorry. Yet we do adhere to ILP notion when describing platform requirement, so 8 is kind of implied anyway. But in case one chooses to switch to CHAR_BIT. I want to remind that not all platforms OpenSSL [still] supports are sufficiently standard compliant. There are platforms that are *partially* compliant or stuck between standards. But I'd say that it would be safe to assume that if CHAR_BIT is not defined, then it's 8. > (Also, such platforms are generally DSPs which are not likely to be > able to run OpenSSL anyway.) As fun fact, OpenSSL does run on TI C6000 series DSP and even optimized for C64x+ and forward. Anyway, this has little to do with problem at hand, as all assumptions made implicitly or explicitly do apply to the platform in question. If it turns to be compiler bug, then no argument about standard compliance would justify it. And we'll face the usual dilemma, do we give in and arrange a kludge (e.g. with #ifdef _MSC_VER), or send user to said compiler vendor... Latter is kind of counter-productive, former is <blank>...
