[cfe-dev] patch for generalizing stdint for n-bit bytes

[Ken Dyck]

On Friday, October 30, 2009 8:42 AM, Ken Dyck wrote:
> On Friday, October 30, 2009 1:06 AM, Chris Lattner wrote:
> > On Oct 29, 2009, at 7:52 AM, Ken Dyck wrote:
> > >> This is a great start, applied as r85481.  Removing the
> > rest would be
> > >> even better :)
> > >
> > > One obstacle I found to simplifying the code is that the
> > char type is
> > > not included in the TargetInfo::IntTy enumeration, making
> > it necessary
> > > to always add a special case for characters. What is the
> > rational for
> > > excluding characters? Would there be any objection to 
> adding a Char 
> > > type to the enum?
> > 
> > It probably was just not needed yet, so noone added it.
> 
> Alright. If there aren't any objections, then, I'll add it 
> and do a more thorough scrub of InitPreprocessor.cpp. 

On second thought, I'm going to leave it out. After tinkering with this
a bit, it didn't really buy us much. Besides, the standard excludes char
from the "standard integer types", which makes the current code closer
to the spec.

I still plan to clean up InitPreprocessor.cpp a bit more, though, which
leads me to another question. 

TargetInfo allows you to override the type, width, and alignment of
several type definitions that are synonyms for the standard integer
types (i.e. wchar_t, char16, char32, intmax_t). It is possible, for
example, to specify int as 16-bits wide, define wchar_t as int, and
wchar_t as 32-bits wide. This is exactly the situation with MSP430
because it overrides the width of int but not of wchar_t, and it leads
to inconsistencies in limits.h and stdint.h. 

Are there any cases where you'd want to specify a width or alignment for
one of these typedefs that is different from the type that it denotes?
If not, I propose that we remove the width and alignment members from
TargetInfo and calculate their values from the type that they denote.

-Ken