discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Openstep Enterprise 4.2


From: David . Ayers
Subject: Re: Openstep Enterprise 4.2
Date: Tue, 30 Apr 2002 11:02:39 +0200

Hi

well actually it's not that simple. I'm not creating this decimal from a string
or a float. It is the result of concrete NSDecimalNumber calculations. (Granted
it seems odd that sending an NSDecimalNumber description results in a string
with seemingly higher precision than definded by OPENSTEP.) But even if I did
create it from a string, I would've been happy, as long as exceeding the
precision would lead to a rounded NSDecimalNumber, which not only compare:'s as
NSOrderingSame, but also returns the same string from description. This is the
problem, that I have two NSDecimalNumbers which compare: as NSOrderingSame yet
return different NSStrings when sent description. Everything would be dandy, if
the precission were exceeded and  both numbers would return the same string! But
claiming they are NSOrderingSame while returning different strings is (IMHO) a
bug. Now I've also verified that the NSDecimal-structs are very different (which
is of no surprise since the produce different descriptions.) What I concider the
bug is to allow loss of percision whilst comparing, (and from checking the
NSDecimalCompare() code of GNUstep, I'm not alone in this assumption :) ) This
is why I would consider it a bug to call NSDecimalNormalize() from
NSDecimalCompare(). Yet since I haven't quite understood the NSDecimal structure
of Openstep 4.2 and the NSDecimalCompact procedure/algorithem, I'm still not
sure whether or not NSDecimalNormalize() might be necessary in some form which
retains the precision.

I've been experimenting with memcpy on function addresses but this is SIGSEGV-
segfautling at every approach so far. I guess all I can do is create an
NSDecimalNumberPoser an either just verify isEqual: with the comparison of the
description or try to finish implementing a corrected NSDecimalCompareBugFixed()
and calling that in NSDecimalNumberPoser compare: and hope that the original
NSDecimalCompare() function isn't used very often. (yet I'm pretty sure it is
and I'm not sure whether that it is worth the effort of reimplementing
NSDecimalCompare() from disassembled code.)

But if it's done nothing else, this thread could be viewed as another prime real
world example of why one should only use free software! (what's the status of
gdl2?)
Thanks for the feedback anyway.

Dave

PS: Please send any responses privatly, since this now really getting out of the
GNUstep realm. Consider it a last call for help from people who might know how
to manipulate the "function-dispatch-table" (if something like this exists)
Maybe I'll try to ask again on the gcc mailing list.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]