This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Builtin types, <limits.h>, <stdint.h> etc.


> I would want __builtin_intmax_t and __builtin_uintmax_t so that
> meaningful testcases for the printf format checking support could be
> written.

If that is the only rationale, then I still can't follow. What is the
target which does not have a well-known compile-time-determinable
intmax_t, so that you need to decide on this type at run-time?

Or, if it is indeed possible to always know at compiler configuration
time, why is it that you need this type?

> The <stdint.h> types may be extended integer types.  I'm saying that it
> would be advantageous for int8_t to be one.  (This being a change from C89
> which did not have any concept of extended integer types with defined
> behaviour in the standard, and did not allow types such as size_t to be
> extended types.)

I see; I didn't know that C99 explicitly allows for additional
integral types, and that <stdint.h> is also meant to give standard
names to these types.

However, I would seriously caution not to introduce additional
integral types into gcc, as they would introduce many new problems.
Let's say we add __byte, which is unsigned 8 bit. What is the rank
(6.3.1.1) of that type? Less then char, apparently. Would that still
meet the expectations of the users?

Also, if such a type would be added, should it be added to C++ as
well? If so, how would it affect overloading, and subsequently
mangling?

Unless this has been studied sufficiently, I'd vote against these
extended types.

Regards,
Martin

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]