[OT] gstdint.h project

Many projects have a need for bitspecific typedefs, and each of them
has the problem to make a header file that defines them, with the
additional need to make short identifiers that do not accidently
redefine the same symbol from another package. SDL is among these.

The unix opengroup were among those to push the topic - as more and
more 64-bit platforms emerged, the long and void* were not anymore
just 32-bit. The idea of an inttypes.h was born and fixed in 1997.
The ISO C9X picked it up and extended the idea far beyond, and called
it stdint.h when C99 was fixed.

Projects can pick this up using these single strictly defined inttypes
whereever there is a need for. However not all platforms have this
standard-C header file so far. Quite some libraries started to typedef
them if the system does not have them - but everywhere a little bit
different, adressing some platforms morre or just don’t, possibly even
in the presence of other library headers to typedef their inttypes
when their configure-script detected missing inttypes too.

The gstdint.h project tries to throw a possible solution into the ring.
First, it provides a single autoconf-macro that projects can reuse in
their configure-scripts, and the generated header can never stomp on
inttypes from other headers from autoconf’ed projects. And secondly it
is a true package with uniquly known header file gstdint.h that other
projects may possibly just make themselves depend on. As you like it.

Now - I have a problem too - most platforms that I have access to,
they are too common - just win32 or unix98 compatible. What about the
weird platforms, possibly some that other inttype-redefines did
never try on, and possibly just fail right away? AFAIK the SDL users
are among those to be part of a project being ported to lots and lots
of platforms while at the same having the need for bitspecific inttypes
in their header declarations. So please, have a look at the gstdint.h
project, download and configure, watch for what the macro detects,
and have a look at the generated file if it looks just right. I’d be
honoured to see the mention your findings in the list of platforms
that gstdint works on.

TIA, Guido http://ac-archive.sf.net/gstdint

P.S. and some day, SDL will be using standard inttypes too, right? :wink:

Guido Draheim wrote:

P.S. and some day, SDL will be using standard inttypes too, right? :wink:

SDL 1.3 will most likely abandon the old “Uint32” typedefs and use C99
inttypes, typedef’ed in an SDL header where needed. I don’t see this
as a problem

Mattias Engdeg?rd wrote:

Guido Draheim wrote:

P.S. and some day, SDL will be using standard inttypes too, right? :wink:

SDL 1.3 will most likely abandon the old “Uint32” typedefs and use C99
inttypes, typedef’ed in an SDL header where needed. I don’t see this
as a problem

exactly, and most lib-projects will do too - switch to C99, typedef where
it is needed - and a third-party project including two such lib-projects
will be offered “redefined typedef” messages, possibly even to a different
basic type. That’s what the ac-macro of gstdint is about, just reuse it
and be sure you don’t get into a problem with other projects using it too.

Possibly, the experiences with platforms can be gathered into one place
instead of being splinteres as is the case right now where everyone is
adding #ifdef-platforms around - which in itself contradicts autoconf
philosophy to detect features and not platform-names. There was no such
generic central place AFAICS, so I did just create it - and that’s
pretty much all about it. Feel free to use it for SDL, and since I have
an interest in the well-being of SDL, I’ll help it as good as I can.

Anyway, good to hear you think too that SDL will switch to inttypes,
well, it’s just the Right Thing to do IMNSHO.

cheers,
– guido http://ac-archive.sf.net/gstdint
GCS/E/S/P C++$++++ ULHS L++w- N++@ d(±) s+a- r+@>+++ y++ 5++X- (geekcode)

Guido Draheim wrote:

Anyway, good to hear you think too that SDL will switch to inttypes,
well, it’s just the Right Thing to do IMNSHO.

it’s not necessarily the right thing to do - we have to be pragmatic

but even using inttypes I see no reason introducing or relying on a new
header file