I would like to help implement stdint.h

I would like to help implement stdint.h

[Jason Catena]

* Goal and approach

I read on your C99 feature status page that "extended integer types in
<stdint.h>" is missing. I would like to help work on this, since I
believe this is a very important feature of the standard that will
significantly increase C program portability.

Since stdint.h is platform-dependent, I was thinking of writing a
small program that would translate a description of the type sizes on
the target to a finished stdint.h file. Alternately, I could create a
library of stdint.h files, but it seems more efficient and flexible to
create it in the fly.

I have a hardcopy and a soft copy of the standard, but my copy does
not include TC1, so I will probably have to pick up the combined book
from the bookstore. I heard that there were a lot of changes to
stdint.h in TC1. I also have Harbison/Steele's fifth edition of _C: A
Reference Manual_, and Rex Jaeschke's _The Dictionary of Standard C_.

I also have to go read the GNU Coding Standard. :)

* My experience with stdint.h

I've been working with code for a decade that has gone through several
major platform changes, and I've found that bit length of types is a
significant porting problem, especially when only one component of a
custom network upgrades to a 64-bit processor, but has to use the same
types as the other components. It's better to state how many bits you
need than hope that you have enough, or that more bits in your type
does not break anything.

I wrote a draft of parts of this file (primarily u/int*_t) for the
codebase at work (Motorola) since all of the system headers seem to be
written against an early version of the standard. I had to put hacks
in my stdint.h to turn off Tandem, Alpha and Solaris' int_types.h.
Our codebase's alternative simply renamed the types (eg, typedef Ulong
unsigned long:(.

* About me

I am running Red Hat Linux 9 at home, so I should be able to
participate through CVS.

I may have to get a Motorola lawyer to sign away my contibutions to
GCC, even if I do it on my own time.

Please let me know if I can be of help, and what further information I
will need to contribute. I found a bug in bugzilla that talks about
stdint.h, but I don't know how well this reflects current thinking.

I have not contributed to GCC or an open-source project before, so I
need to get up to speed with this. I have been writing C since 1991,
and I am fond of f/lex (and bison/yacc where needed) to parse input
data). I'm less strong on C++ and Java. But I could probably write a
shell script to do the translation if necessary.

Regards,
Jason Catena

Re: I would like to help implement stdint.h

[Joseph S. Myers]

On Fri, 10 Oct 2003, Jason Catena wrote:

> Since stdint.h is platform-dependent, I was thinking of writing a
> small program that would translate a description of the type sizes on
> the target to a finished stdint.h file. Alternately, I could create a
> library of stdint.h files, but it seems more efficient and flexible to
> create it in the fly.

The current thinking is that you should follow the same approach now used
for <limits.h> and <float.h> - that is, have a single stdint.h file that
uses macros predefined by the compiler to determine the types involved.  
Because many targets can have their type sizes changed at compiler runtime
with -m options, generating a <stdint.h> file at compiler build time isn't
a feasible approach.

There will need to be sensible defaults for the types, as well as target
macros to override them.  A fair amount of work will be involved in going
through supported targets which have their own <stdint.h>, such as all
glibc-based targets, to ensure that GCC's types agree with those systems'
types.  This is also necessary on systems which have <inttypes.h> but not
<stdint.h> (such as Solaris).  Note that GCC will also need to gain an
awareness of sig_atomic_t, which it previously hasn't needed to know about
(and some embedded targets may not have at all; see DR#248).

<stdint.h> may also need to be compatible with what various systems' other
headers expect of it or of <inttypes.h> (try to make something more
comprehensible than GCC's <stddef.h>).

Some fixincludes work may also be needed to make existing system headers
work well with GCC's <stdint.h>, especially on systems which have
<inttypes.h> only.

-- 
Joseph S. Myers
jsm@polyomino.org.uk