Openstep Enterprise 4.2

[David . Ayers]

Hi all,

Ok I still owe some of you some replies, and they are in the making. (Trying to
be rather concrete.) But my "day time" job has got me spining at the moment. I
figured, since a lot of ex-Opensteppers are on this list maybe someone could
help me. (I hope no one fells that I'm abusing this list.) Here's my problem.

It actually is problem of Openstep 4.2 Enterprise (i.e. NT/W2K) (+/- Y2k Patch)
(maybe other Versions of Openstep also ?)

The short Version:
NSDecimalCompare(12.5, 12.5000000000000000000000000000000000121)
evaluates to NSOrderingSame !!!

Does any one know of a patch? Disassembling NSDecimalCompare reveals that it
actually calls NSDecimalNormalize() in this case. I figure  it deletes trailing
digits in the mantissa enough to make them equal! Right now I'm attempting to
"reengineer" the function NSDecimalCompare (and it seems rather time consuming)
to write a replacement, and then I was wondering whether I could redirect the
NSDecimalCompare symbol to my new function. Has anyone done something like this
before? Does anyone know that this can't be done?

The long Version
In an EOF Application some intesive calculations lead to values with minor
rounding errors. During the processing of [EOEditingContext commitChanges] the
EODatabaseContext executes a private method called
processSnapshotForDatabaseOperation:(EODatabaseOperation*). During this
processing the adaptor is asked to provide a value which can be put in the
datase through fetchedValueForValue:attribute:. This returns the correctly
rounden value. yet before actually replacing the old value with the returned
value in the row dictionary the processSnapshotForDatabaseOperation:
implementation checks whether the to are equal by invoking isEqual: which
invokes compare: which in turn calls NSDecimalCompare which falsely claims yes!
So the value isn't replaced, and the adaptor send description to the
NSDecimalNumber to create the c-string
'12.5000000000000000000000000000000000121' for the database API and the database
sais "I don't think so" and rolls back.

Ok I've been able to rewrite processSnapshotForDatabaseOperation: skipping the
isEqual: and always replacing the object. But the real bummer is that one can't
count on correct decimal comparisons in other cases and that gives me a slight
headache. (I've even have a college mention an actual error in devisions, but I
haven't been able to reproduce it and track it down, But if someone has an
example for that, I'd be glad for the hint.)


Thanx 4 your time.
Dave