[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