diff options
author | Quincey Koziol <koziol@hdfgroup.org> | 2003-11-24 16:47:18 (GMT) |
---|---|---|
committer | Quincey Koziol <koziol@hdfgroup.org> | 2003-11-24 16:47:18 (GMT) |
commit | 6d8dd9c50412803fd3cc3af18c4e618c3b97cec3 (patch) | |
tree | e23e841019af738a69c2bf5633bd3a671dd4e3fb /pablo | |
parent | 2106568c9cf25cc350e688276268465366a50d8f (diff) | |
download | hdf5-6d8dd9c50412803fd3cc3af18c4e618c3b97cec3.zip hdf5-6d8dd9c50412803fd3cc3af18c4e618c3b97cec3.tar.gz hdf5-6d8dd9c50412803fd3cc3af18c4e618c3b97cec3.tar.bz2 |
[svn-r7875] Purpose:
Omnibus floating-point bug fix changes
Description:
There are a number of problems in the floating-point conversion code that
were exposed by Ray's recent int<->float checkin:
- The 'my_isnan' code in test/dtypes.c was broken and would always return
true. The meant that the actual values in the float<->float conversion
tests were _never_ checked, hiding the other bugs included in this
checkin.
- A recent change I made to the type conversion code used "FLT_MIN" instead
of "-FLT_MAX" for the most negative 'float' value for the double->float
conversion, which meant that any the negative number that was converted
from a double to a float would have been mapped to zero, essentially.
- A change that Robb appeared to have made ~2.5 years ago to the "generic"
float->float conversion routine appears to be incorrect and I've backed
it out.
- Floating-point conversions on SGI's which converted denormalized values
would be mapped to zero instead of being propertly preserved in the new
type. This was addressed by an SGI-specific system call to prevent the
behavior.
Solution:
Described above, generally.
Platforms tested:
FreeBSD 4.9 (sleipnir)
h5committest
Misc. update:
release_docs/RELEASE update forthcoming...
Diffstat (limited to 'pablo')
0 files changed, 0 insertions, 0 deletions