thiago at kde.org
Thu Nov 2 13:11:06 GMT 2006
Cristian Tibirna wrote:
>But my question is related to this exactly. It seems on 32 bits the
> conversion from int to long int through a qdatastream is ominous.
It's a Qt3 issue: QDataStream had operators for "long". Not so anymore in
This is one of the reasons why the "kdatastream.h" header was invented for
DCOP. Another was the necessity of setting the stream version.
> on 64 bits, such conversions bring problems (I don't understand exactly
> why, since this particular case is a widening cast). This, of course,
> has a deep impact on the design of classes that use dcop (e.g.
> kdeprintd would require exhaustive replacing of int by long int
> throughout its methods, to fix this properly, without a need for
The problem here is one of the inherent problems with DCOP that D-Bus
tries to solve: the parameter types are not part of the protocol itself.
DCOP just sends a large byte array with its parameters inside. There's no
telling that one give parameter occupies 4 or 8 bytes.
So it's just a convention between caller and callee. The parameter could
be called "quad_t" but only 1 byte could be read...
>So, is there a feasible way of checking that such type non-conversions
> don't occur? (i.e. catched as errors or something).
Yes, use DCOPRef::call instead of DCOPClient::call.
The latter takes the full function name as a parameter, but the former
doesn't. Instead, it creates such a signature from the parameters that it
was given. So, if you get one parameter type wrong, you'll end up with
your call failing in all platforms (like D-Bus), because there will be no
such function overload.
>> On D-Bus, this would have generated an error on all platforms. For one
>> thing, the dubious type "long" isn't present in QVariant, so you're
>> forced to choose between int (always 32-bit) and qlonglong (always
>And this is what I wanted have spelled out.
And in so choosing, if you choose the wrong one, you'll get an
UnknownMethod error back (which KDE code tends to ignore; maybe we should
make QDBusReply report any errors via qDebug()?).
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the kde-core-devel