int32 vs uint32 issues with untyped language bindings

Havoc Pennington hp at
Mon Dec 27 21:06:55 PST 2004


There are essentially two options that I see:

 1. some implicit conversions in libdbus, e.g.
      variant->whatever it contains
      - what if the conversion can fail, e.g. number out of range etc.
      - it is a fair bit more code/complexity and probably too
        expensive to do fully generically, i.e. it's easy to do 
        variant->int32 but arrayofarrayofarrayofvariant->
        arrayofarrayofarrayofint32 is sort of a pain in the ass.
        And slow.
      - ruins my plan to never alloc new memory when accessing 
        args (i.e. I want to switch to returning arrays
        and strings by const pointer)

 2. awareness of typelibs by bindings
      the idea here is that the binding calls Introspect() at runtime 
      (or somehow gets the "IDL" at "compile time") and uses that to 
      know what casts to perform

      - initial performance hit each time a binding uses a new interface
      - or alternately, annoying problem of installing and loading 
      - possible loss of reliability for dynamic bindings vs. static
        bindings (i.e. dynamic bindings have to rely on the interface
        implementation correctly setting up Introspect())

While I was thinking of doing 1 and even have a note in TODO about it,
at the moment I'm feeling pretty sure that 2 is the right thing to do.

If it turns out to be needed we can do some efficiency hacks to speed up
obtaining the typelib data. We also need to do a plain C "binding"
probably that implements Introspect() for you. And of course people can
do "dpack" style bindings that avoid the issues if they prefer.

There is one possible quick fix that might help a lot: get rid of uint
and only have int. However, that still leaves int32 vs. int64 and I
really like having the uint types available so you can easily pass
through uint data without worrying about some funny lossiness or
casting. People casting uints to ints and back wouldn't help python


More information about the dbus mailing list