Opened 9 years ago
Last modified 2 weeks ago
#631 assigned defect
trunc(768.3156) == 770?!
Reported by: | Jiri Svoboda | Owned by: | Jiří Zárevúcky |
---|---|---|---|
Priority: | major | Milestone: | |
Component: | helenos/unspecified | Version: | mainline |
Keywords: | Cc: | ||
Blocker for: | Depends on: | ||
See also: |
Description
Adding the code fragment
TPRINTF("trunc(768.3156)=%lf\n", trunc(768.3156));
to tester yields the output
trunc(768.3156)=770.000000
However the float2 test succeeds, because after multiplication by precision and conversion to integer the result is as expected.
Change History (3)
comment:1 by , 9 years ago
comment:2 by , 9 years ago
OK, it's very probably a bug in printf and not in the arithmetic functions. The following code
printf("768.3156=%lf\n", 768.3156); printf("768.3150=%lf\n", 768.3150); printf("768.3100=%lf\n", 768.3100); printf("768.3000=%lf\n", 768.3000); printf("768.0000=%lf\n", 768.0000);
produces the following output
768.3156=768.315600 768.3150=768.315000 768.3100=768.310000 768.3000=768.300000 768.0000=770.000000
comment:3 by , 2 weeks ago
Owner: | set to |
---|---|
Status: | new → assigned |
Note:
See TracTickets
for help on using tickets.
On what platform do you observe this? Could it be an issue in the printf?
If I port both the generic code (
uspace/lib/math/generic/trunc.c
) and the ia32-specific FPU code to Linux, I don't observe this behavior.