[firstname.lastname@example.org: Bug#290306: dbus-1-dev: silly typedefs]
Thu Jan 13 12:59:28 PST 2005
On Thu, 2005-01-13 at 21:19 +0100, Guus Sliepen wrote:
> On Thu, Jan 13, 2005 at 02:31:37PM -0500, Havoc Pennington wrote:
> > > It also introduces its own types, while there are perfectly well defined
> > > and standardised types that do exactly what dbus needs in stdint.h
> > > (int16_t, uint16_t, etc.) and stdbool.h (bool). At best DBus's
> > > proprietary typedefs will confuse a programmer, and in the worst case it
> > > will break on other architectures.
> > These aren't portable enough yet. Programmers can assume that uint16_t
> > is the same as dbus_uint16_t though.
> What do you mean, they aren't portable enough? They are MADE to be
> portable! You can check for the availability of these types with
> autoconf. If you compile on a system that doesn't define them (I think
> you have to look very hard for those), then you can always typedef them
> yourself as a last resort. I have more trust in the standard header
> files getting the typedefs right on all architectures than anyone else.
The "emulate glibc if it's not there" approach isn't used much in
desktop software, we usually use the "portable wrappers" approach as
with Qt and GLib. I don't think that debate is very on-topic for this
list, but it extends well beyond typedefs. See dbus-sysdeps.h, or all of
Even outside of software, see vsftpd for example and their secure coding
guidelines which include wrapping all system headers/functions as a
More information about the dbus