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.


On Sat, 8 Jul 2000, Martin v. Loewis wrote:

> I'd rather expect that these options exist for certain freestanding
> environments, to ease porting so that adding a GCC target would not be
> necessary; instead, the command line option could be used. In these
> cases, <stdint.h> would be written by the same person that also
> defines the set of command line options that must be used.

If a copy of GCC can be compiled on which it might be meaningful to use
different combinations of the options, I would say it is the job of GCC to
provide the conforming freestanding implementation (possibly by providing
multiple versions of <stdint.h> for each environment supported, which I
suppose would be somewhat like multilibs).

> > and the natural extension to cover %j would add intmax_type_node,
> > uintmax_type_node 
> 
> Yes, that would be the natural extension. I don't see the need for
> magic predefined typedefs, though - just the need for additional
> global tree nodes.

I would want __builtin_intmax_t and __builtin_uintmax_t so that meaningful
testcases for the printf format checking support could be written.  There
are already magic types in GCC with pretty specialised uses (e.g. the G77
types in the C compiler).

What is the purpose of the __builtin_size_t typedef?  (CC:ed to Gavin
Romig-Koch who added it last December.)  It doesn't seem to be used
anywhere in the GCC source tree, and since C89 requires that size_t be one
of the standard C89 types (Clive Feather's DR#067), using it for the
externally visible size_t in <stddef.h> would require great care not to
break C89 conformance.

> For it not to have this property, it would have to be 
> 
> typedef signed short int8_t;
> 
> and short would have to be a type of exactly 8 bits, right? Well, this
> would be non-conforming, as 5.2.4.2.1 requires short to have at least
> 16 bits. As a result, int8_t must be the same as signed char (or
> potentially as char). Therefore, int8_t* can legally alias with any
> other pointer in C99.

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.)

-- 
Joseph S. Myers
jsm28@cam.ac.uk


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