RPM Community Forums

Mailing List Message of <rpm-devel>

Re: - jbj: replace <stdint.h> with private typedefs.

From: Ralf S. Engelschall <rse+rpm-devel@rpm5.org>
Date: Thu 07 Aug 2008 - 21:14:26 CEST
Message-ID: <20080807191426.GA27714@engelschall.com>
On Thu, Aug 07, 2008, Alexey Tourbin wrote:

> On Thu, Aug 07, 2008 at 08:40:26PM +0200, Ralf S. Engelschall wrote:
> > On Thu, Aug 07, 2008, Alexey Tourbin wrote:
> >
> > > [...]
> > > >     - jbj: replace <stdint.h> with private typedefs.
> > >
> > > Why private typedefs are any better?
> >
> > For instance because the private ones are available everywhere while
> > the <stdint.h> ones require at least a C99 environment which in turn
> > unnecessarily increases the entry barrier for a bootstrapping tool like
> > RPM when it comes to non-Linux platforms.
> Arguably a better approach is to define uint32_t etc. on systems that
> miss them instead of introducing rpmuint32_t.

Can be done when building RPM itself, but is a larger problem for the
RPM header files when built outside the RPM source tree (where RPM's
own Autoconf results are not available). Sure, can be also solved by
in-place providing the Autoconf results directly in the headers, but
Jeff decided to go the way of own typedefs and I personally see no major
drawback there. It at least avoids all the trouble related to building
RPM headers outside the RPM source tree rather easily.

> My $EDITOR can highlight uint32_t but knows nothing about rpmuint32_t.
> As a developer, I'm disappointed about reading the code made harder.

Ah, ok, your $EDITOR seems to be at least not Vim, because in my $EDITOR
everything matching /[a-zA-Z_][a-zA-Z_0-9]*_t/ seems to be correctly
syntax highlighted as a type symbol (either by default or I configured
it somewhere to to this and just forgot). But your $EDITOR certainly
also can be told to recognize rpmuint32_t, can't it?

                                       Ralf S. Engelschall
Received on Thu Aug 7 21:14:39 2008
Driven by Jeff Johnson and the RPM project team.
Hosted by OpenPKG and Ralf S. Engelschall.
Powered by FreeBSD and OpenPKG.