On Oct 28, 2007, at 4:10 AM, Ralf S. Engelschall wrote:

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

Absolutely agree. The issue (imho) is the naming "int_32" vs
the (far more prevalent usage in 2007) "int32_t".

OTOH, a C99 environment is needed iff "int32_t" (or <stdint.h>)
is not defined. I'm certainly not suggesting no retrofit of <stdinth>
using autoconf tests, that's silly. OTOH, the useful (imho) typedef's
for rpm are rpmTag, rpmTagType, rpmTagCount and rpmTagData, not
Yet Another Integer Type Renaming.

(aside) The "long long" type is rather unportable too, the basic  
reason why
rpm has never had a 64bit integer type. I have not heard any problem  
reports
since adding int_64 2-3 years ago, so presumably uglix compilers can  
handle "long long"
these days.

Meanwhile, "unsigned integers always" may need some further thought.
Easy enough to add signed integer pointers back to the rpmTagData union
if necessary. But the semantic convention for what is contained in  
Header tags,
not what is implemented within rpm, is perhaps trickier.

73 de Jeff