64bitness

[Cristian Tibirna]

On 2 November 2006 05:36, Thiago Macieira wrote:
>
> Your patch was:
> >-       input << info << i18n( "Authentication failed (user name=%1)"
> > ).arg( info.username ) << 0 << req->seqNbr;
> >+       input << info << i18n( "Authentication failed (user name=%1)"
> > ).arg( info.username ) << 0L << (long int) req->seqNbr;
> >
> > if ( callingDcopClient()->call( "kded", "kpasswdserver",
> > "queryAuthInfo(KIO::AuthInfo,QString,long int,long int)", params,
> > replyType, reply ) )
>
> As you can see from the signature in queryAuthInfo, the last two
> parameters are "long int". You were passing "int". That's why it wasn't
> working.

I _did_ understand the patch perfectly, Thiago ;-). Thanks for the 
reexplanation anyways ;-)

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

So, is there a feasible way of checking that such type non-conversions don't 
occur? (i.e. catched as errors or something).


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

Thanks a lot.

-- 
Cristian Tibirna
KDE developer .. tibirna at kde.org .. http://www.kde.org