On 8/5/2013 9:42 PM, Keith Thompson wrote:

> "James Harris" <(E-Mail Removed)> writes:

>> "Keith Thompson" <(E-Mail Removed)> wrote in message

>> news:(E-Mail Removed)...

> [...]

>> FWIW the section of the header which defines the 64-bit types is currently

>> as follows. It's not fully tested yet.

>>

>> /*

>> * 64-bit integers

>> */

>>

>> #if INT_MAX == 0x7fffffffffffffff

>> typedef signed int s64_t;

>> #elif LONG_MAX == 0x7fffffffffffffff

>> typedef signed long s64_t;

>> #elif LLONG_MAX == 0x7fffffffffffffff

>> typedef signed long long s64_t;

>> #else

>> typedef struct {u32_t low; s32_t high;} s64_t; /* Limited use */

>> #endif

>

> This might cause problems if the 16-bit compiler's preprocessor can't

> handle a 64-bit constant like 0x7fffffffffffffff. I'm not sure there's

> a really good solution. But it's likely you'll only get some warnings,

> and you can ignore them as long as it selects the right definition.

> [...]
One approach is to write tests like

#if ((INT_MAX >> 16) >> 16) == 0x7fffffff

Details: We know that preprocessor arithmetic is equivalent to that

of the execution environment's widest integer types, which are no

narrower than `[unsigned] long', which are at least 32 bits wide.

Therefore, the 16-bit shifts above are well-defined (although a

31-bit shift of a signed value might not be), and two of them

eliminate 32 low-order bits. Also, we know that INT_MAX is one

less than a power of two, so if any 1-bits remain after shifting

we can conclude that all the eliminated bits were also 1's.

Similar arrangements like

#if ((INT_MAX >> 30) >> 30) == 0x7

would also work, in pretty much the same way.

--

Eric Sosman

http://www.velocityreviews.com/forums/(E-Mail Removed)d