[cfe-commits] r63977 - in /cfe/trunk/lib/Headers: limits.h stdint.h
Chris Lattner
sabre at nondot.org
Fri Feb 6 22:36:01 PST 2009
On Feb 6, 2009, at 5:25 PM, Eli Friedman wrote:
> On Fri, Feb 6, 2009 at 2:59 PM, Chris Lattner <sabre at nondot.org>
> wrote:
>> +#define INT8_MAX ((int8_t)127)
>> +#define INT8_MIN ((int8_t)-128)
>> +#define UINT8_MAX ((uint8_t)255)
>
> Gah! I can't believe I didn't spot this. Casts aren't allowed here.
> In this case, they're unnecessary anyway.
Yeah, you're right, this is the same bug as my limits.h botch, sorry
fixed!
>>
>> +#define UINT64_MAX ((uint64_t)18446744073709551615ULL)
>
> Same issue. Also, this is wrong if int64_t doesn't map to long long;
> do we make any guarantees here?
All targets with 64-bit datatypes currently handle them with long
long, I'm inclined to keep it this way for simplicity until/if we ever
need to change it.
>> +#define INT32_MAX ((int32_t)2147483647LL)
>> +#define INT32_MIN ((int32_t)(-2147483647LL-1))
>> +#define UINT32_MAX ((uint32_t)4294967295ULL)
>
> Same issue; you'll need some ifdefs to get this right for platforms
> where int32_t isn't int. Note that the rule is that INT32_MAX is
> required to have type int32_t.
Yes. You're right, same problem with the _C macros. I don't really
see a good solution for this, other than adding a bunch of junk to
Preprocessor.cpp that defines a ton of builtin macros. Do you have a
better idea?
-Chris
More information about the cfe-commits
mailing list