[cfe-dev] Source information for types

[Argyrios Kyrtzidis]

On Aug 14, 2009, at 2:46 AM, Enea Zaffanella wrote:

> Argyrios Kyrtzidis wrote:
>> For the "adherence to coding standards" case, isn't it more  
>> appropriate to see the tokens without macro expansion ? e.g
>> int unsigned x;
>> COOL_MACRO y;
>> "COOL_MACRO" may expand to "int unsigned" but whether the compiler  
>> sees  "int" or "int unsigned" doesn't matter, we are really  
>> interested in what the user wrote, right ?
>
> Well, a colleague made me remember that coding standard (in their  
> strict interpretation) are not the only application for this info.
>
> Distinguishing between "int" and "signed int" is sometimes necessary  
> to avoid implementation-defined behavior and hence it is important  
> to ensure portability. This happens in the case of bitfields, whose  
> signedness is implementation defined.
>
> Anyway, we would like to better understand what you mean by
> "memory usage for type source info should be reasonable enough".
> We ask because, for the (qualified) _basic_ types mentioned in the  
> C89/99 standards, the needed information can be extracted from the  
> corresponding type specifiers and suitably encoded in 64 bits:  
> rather than storing info about locations, we could encode the  
> presence/absence of type specifiers and type qualifiers (and even  
> storage classes), together with their textual ordering.
>
> Would that be reasonable?

Seems reasonable. Later we can test on some "big" headers and see how  
much memory it takes.

-Argiris

>
> Cheers,
> Enea Zaffanella.
>