On Sat, Oct 27, 2007, Jeff Johnson wrote:

> Last century, there was a reason to have these internal integer
> data typedefs (from header.h):
>
>     /* XXX hpux needs -Ae in CFLAGS to grok this */
>     typedef long long int int_64;
>     typedef int int_32;
>     typedef short int int_16;
>     typedef char int_8;
>
>     /* XXX hpux needs -Ae in CFLAGS to grok this */
>     typedef unsigned long long int uint_64;
>     typedef unsigned int uint_32;
>     typedef unsigned short uint_16;
>     typedef unsigned char uint_8;
>
> I see no reason not to switch to <stdint.h> types (as rpm.org has recently
> done).
> [...]
> So I'm gonna do the following:
>     1) convert to using <stdint.h> types
>     2) change all pointers to tag integer data to be unsigned.
>
> Opinions?

I'm personally against this and think rpm.org made an error here.
Switching to an unconditional use of <stdint.h> means that RPM 5 would
require a C99 environment. Sure, we are already approaching 2008, but
nevertheless RPM is some sort of a bootstrapping tool and for this a
C90 compiler is often available only. For rpm.org and their mainly
Linux-only focus this is not important as they can nearly safely assume
GCC. But for rpm5.org we should be more careful. We should convert
to <stdint.h> types _BUT_ still provide the necessary Autoconf glue
code and provide reasonable fallback definitions for all used types in
case <stdint.h> is not available. Just unconditionally use <stdint.h>
currently would still make RPM 5 too unportable and I don't think this
is worth it.
                                       Ralf S. Engelschall
                                       rse@engelschall.com
                                       www.engelschall.com