Thank you, now I see, it was the next test that was failing. Am 04.03.2011 11:10, schrieb Philippe Roussel: > Le vendredi 04 mars 2011 à 10:27 +0100, Fred Kiefer a écrit : >> Now this is interesting. Why is this the case and how does this code >> behave on MacOSX? If it is only on GNUstep that the order in which we >> use two independent operations is important, then we should rather fix >> our code and not our tests. > > The test was wrong : it initialized num with 1.01 for the 'Handle > leading zeroes in fractional' test and then tested rounding as if num > was still equal to 1234.567. > > Philippe > >> >> Am 04.03.2011 09:06, schrieb Philippe Roussel: >>> One of the tests in basic.m (round up for fractional part >0.5) is >>> failing only because of code ordering. The appended patch fixes it. >>> >>> Philippe >>> >>> Index: base/NSNumberFormatter/basic.m >>> =================================================================== >>> --- base/NSNumberFormatter/basic.m (revision 32445) >>> +++ base/NSNumberFormatter/basic.m (working copy) >>> @@ -15,16 +15,14 @@ >>> "+[NSNumberFormatter alloc] returns a NSNumberFormatter"); >>> >>> fmt = [[[NSNumberFormatter alloc] init] autorelease]; >>> - num = [[[NSNumber alloc] initWithFloat: 1234.567] autorelease]; >>> >>> - str = [fmt stringForObjectValue: num]; >>> - >>> - PASS_EQUAL(str, @"1,234.57", "default format same as Cocoa"); >>> - >>> num = [[[NSNumber alloc] initWithFloat: 1.01] autorelease]; >>> PASS_EQUAL([fmt stringFromNumber: num], @"1.01", >>> "Handle leading zeroes in fractional part: 1.01"); >>> >>> + num = [[[NSNumber alloc] initWithFloat: 1234.567] autorelease]; >>> + str = [fmt stringForObjectValue: num]; >>> + PASS_EQUAL(str, @"1,234.57", "default format same as Cocoa"); >>> >>> [fmt setAllowsFloats: NO]; >>> PASS_EQUAL([fmt stringForObjectValue: num], @"1,235",
_______________________________________________ Gnustep-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnustep-dev
