From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11606 invoked by alias); 19 Aug 2004 22:27:11 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 11588 invoked by alias); 19 Aug 2004 22:27:09 -0000 Date: Thu, 19 Aug 2004 22:27:00 -0000 Message-ID: <20040819222709.11587.qmail@sourceware.org> From: "jsm at polyomino dot org dot uk" To: gcc-bugs@gcc.gnu.org In-Reply-To: <20000807074601.448.jsm-gccbugs@polyomino.org.uk> References: <20000807074601.448.jsm-gccbugs@polyomino.org.uk> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug c/448] -related issues (C99 issues) X-Bugzilla-Reason: CC X-SW-Source: 2004-08/txt/msg02020.txt.bz2 List-Id: ------- Additional Comments From jsm at polyomino dot org dot uk 2004-08-19 22:26 ------- Subject: Re: -related issues (C99 issues) On Thu, 19 Aug 2004, geoffk at gcc dot gnu dot org wrote: > which defines the typedefs based on information in the machine > description. That information doesn't exist yet, so you'd have to add > it, with suitable defaults computed from the sizes of the types (perhaps > using the same algorithm that __attribute__((mode)) uses. The > information has to match the system's idea from inttypes.h, including > such details as 'long' vs. 'int' even if they are both the same size. You will, in any case, need lots of target macros to allow for the defaults to be overridden. The logic isn't currently present to get the type of the macros for type limits such as UINT16_MAX correct (when an unsigned type has a limit of type int because the type promotes to int), but this is easy to do. (At present that logic for USHRT_MAX and UCHAR_MAX is in .) The INTN_C, INTMAX_C macros also need to be defined (to concatenate an appropriate suffix). Note the footnotes about __STDC_LIMIT_MACROS, __STDC_CONSTANT_MACROS and C++. > On some systems, the same types can be defined in other headers, so the > #pragma would need to only define a particular type if it hasn't been > defined already. Equally, other headers may want to redefine the types later. Either you make sure duplication is OK for both C and C++ or you interoperate with the existing systems used in system headers. For example, current glibc uses /* There is some amount of overlap with as known by inet code */ #ifndef __int8_t_defined # define __int8_t_defined typedef signed char int8_t; ... whereas older glibc used in some places a convention of the form # ifndef intptr_t typedef long int intptr_t; ... You should arrange for error messages mentioning definitions from the pragma to give the line number of the #pragma in as the line number of both the typedefs and the macro definitions, to avoid making this approach too confusing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=448