[cfe-commits] r63977 - in /cfe/trunk/lib/Headers: limits.h stdint.h

[Chris Lattner]

On Feb 6, 2009, at 5:06 PM, Eli Friedman wrote:

> On Fri, Feb 6, 2009 at 2:59 PM, Chris Lattner <sabre at nondot.org>  
> wrote:
>> add a stdint.h header.
>
> Do we support the search path magic to make this work correctly with
> the system stdint.h?

What do you mean?  This should completely replace a system stdint.h.

>> + * Since we only support pow-2 targets, these map directly to  
>> exact width types.
>
> Does gcc always define these the same way?  I suppose I can't think of
> any target where it makes a significant difference, but we probably
> want to match if possible.

What do you mean always? :)

One of the really frustrating things about working on these headers is  
that GCC's logic for dealing with this stuff is incredibly convoluted,  
so I basically just went with what the standard says and some minimal  
testing and cross-checking with what happens on darwin.  I agree that  
we should make things match where possible, but I think that GCC also  
does certain things really wrong.

JSM has an interesting patch queued up for GCC 4.5 for a new GCC  
stdint.h for example, but that requires the preprocessor implicitly  
#defining a ton more macros than I added.  I generally don't like the  
preprocessor #defining pointless things, because that directly impacts  
startup time.

>
>
>> +/* 7.18.4.2 Macros for greatest-width integer constants. */
>> +#define INTMAX_C(v)  (v ## LL)
>> +#define UINTMAX_C(v) (v ## ULL)
>
> Not sure if it matters, but is this correct for targets where intmax_t
> != long long?

No idea, probably not. :)

-Chris