Re: mingw compilation of base broken

[Fred Kiefer]

> > > --- Running tests in base/NSNumber ---
> > >
> > > base/NSNumber/test00.m:
> > > Failed test: test00.m:102 ... NSDecimalNumber numberWithInt: works
> > > Failed test: test00.m:107 ... NSDecimalNumber doubleValue works
> > > Failed test: test00.m:111 ... NSDecimalNumber charValue works
> > > Failed test: test00.m:113 ... NSDecimalNumber intValue works
> > > Failed test: test00.m:115 ... NSDecimalNumber integerValue works
> > > Failed test: test00.m:117 ... NSDecimalNumber longValue works
> > > Failed test: test00.m:119 ... NSDecimalNumber longLongValue works
> > > Failed test: test00.m:121 ... NSDecimalNumber shortValue works
> > > Failed test: test00.m:123 ... NSDecimalNumber unsignedCharValue works
> > > Failed test: test00.m:125 ... NSDecimalNumber unsignedIntValue works
> > > Failed test: test00.m:127 ... NSDecimalNumber unsignedIntegerValue works
> > > Failed test: test00.m:129 ... NSDecimalNumber unsignedLongValue works
> > > Failed test: test00.m:133 ... NSDecimalNumber unsignedShortValue works

I looked into these test results in some detail and the behaviour is 
really strange. The generated NSDecimalNumber seems to have the correct 
value, using the description method on the objects yields the correct 
result. But when extracting the number from the object things go wrong 
for some types. It works for float, bool and unsigned long long, but for 
the other types we get a slightly different value. As all these 
extraction methods are implemented as simple type cast something must go 
wrong there:

- (int) intValue
{
  return (int)NSDecimalDouble(&data);
}

- (double) doubleValue
{
  return NSDecimalDouble(&data);
}

How do these two go wrong while the next one seems to work?

- (float) floatValue
{
  return (float)NSDecimalDouble(&data);
}


If I remember correctly, this isn't new behaviour. I tried to figure out 
at least one time before what is going on here, but failed.


I found one rather interesting answer to gcc quirks on MinGW, but this 
really doesn't apply to our case. It just makes it clear that we are 
talking about a very specific platform here:

http://stackoverflow.com/questions/7134547/gcc-printf-and-long-double-leads-to-wrong-output-c-type-conversion-messes-up