Cristian Tibirna tibirna at kde.org
Thu Nov 2 12:31:23 GMT 2006

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

More information about the kde-core-devel mailing list