int32 vs uint32 issues with untyped language bindings
Havoc Pennington
hp at redhat.com
Mon Dec 27 21:06:55 PST 2004
Hi,
There are essentially two options that I see:
1. some implicit conversions in libdbus, e.g.
int32->int64
variant->whatever it contains
int32->uint32
problems:
- 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
problems:
- initial performance hit each time a binding uses a new interface
- or alternately, annoying problem of installing and loading
typelibs
- 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
either.
Havoc
More information about the dbus
mailing list