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
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
And this is what I wanted have spelled out.
Thanks a lot.
KDE developer .. tibirna at kde.org .. http://www.kde.org
More information about the kde-core-devel