int32 vs uint32 issues with untyped language bindings

John (J5) Palmieri johnp at
Mon Dec 27 08:31:25 PST 2004

On Mon, 2004-12-27 at 16:13 +0000, Daniel P. Berrange wrote:
> On Mon, Dec 27, 2004 at 08:50:53AM -0500, Andy Wingo wrote:
> > On Sun, 26 Dec 2004, John (J5) Palmieri wrote:
> > > There seems to be an issue with the ability for untyped language
> > > bindings to deal with dbus methods that require uint parameters.
> > 
> > Guile's bindings allow you to add optional type specifiers:
> > 
> >
> For the Perl bindings I've ended up adding a 'dpack' method for
> specifying types explicitly. For example in a method returning
> an signed int, instead of doing
>   my $pid = fork();
>   ... do some stuff ...
>   return $pid;
> You would have
>   my $pid = fork();
>   ... do some stuff ...
>   return dpack("i", $pid);
> So, irrespective whether Perl (or the fork() method in particular) thinks
> (or decided) that the scalar $pid is currently a  string, int or float, as 
> the programmer I know PIDs are signed ints and thus specify 'i' as the format
> string. I so far haven't found the burden of adding dpack() calls to be very
> significant - particular since it gives you 100% reliable typing, removing a
> whole class of unpredictable bugs. For the record, the format specifiers 
> I've defined so far are
>   o - boolean
>   b - byte
>   s - string
>   i - int32
>   I - unsigned int32
>   l - int64
>   L - unsigned in64
>   d - double
> Regards,
> Dan.

This all sounds so wrong for a weak typed language.  Having it as an
option for those who care about types doesn't sound bad at all but using
it as a workaround just make things messy.  It is one of those
annoyances that creates inconsistencies in the language.  We already
have the ability to get a message iterator and append specific types in
the low level python bindings but we keep them there because we really
don't want developers using them.  It really should all be transparent.
Services should be required to register and export their signatures.


More information about the dbus mailing list