64bitness

[Thiago Macieira]

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 
Qt4.

This is one of the reasons why the "kdatastream.h" header was invented for 
DCOP. Another was the necessity of setting the stream version.

> But 
> 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
> casts).

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
>> 64-bit).
>
>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
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20061102/e449b99a/attachment.sig>