|Anonymous | Login | Signup for a new account||2016-08-28 12:30 CEST|
|Main | My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0004486||OCaml||OCaml general||public||2008-01-22 20:37||2013-08-31 12:44|
|Status||closed||Resolution||no change required|
|Target Version||Fixed in Version|
|Summary||0004486: Bug with the serialization of double for custom value|
|Description||The serialization and deserialization function for double (needed to handle custom value when writing a FFI) in byterun/intern.c and byterun/extern.c are incoherent:|
- The function caml_serialize_float_8 in extern.c calls the function caml_serialize_block_8 which depends on the ARCH_BIG_ENDIAN variable.
- The function caml_deserialize_float_8 in intern.c calls the function caml_deserialize_float_8 which depends on the ARCH_FLOAT_ENDIANNESS variable and performs more work.
Therefore double variables can not be marshalled with the *serialize_float_8 functions when ARCH_FLOAT_ENDIANNESS is neither 0x01234567 nor 0x76543210 which seems to be my case (INTEL64 processor with 64 bits Linux).
|Tags||No tags attached.|
Fixed in working sources, will be in release 3.11. Note however that the bug affects only architectures where floats are neither big-endian nor little-endian, namely ARM with the old ABI. On IA64 or x86-64, the buggy implementation of caml_serialize_float_8 should still produce correct output.
Mathias Kende (reporter)
I'm reoppening the thread because I think that the issue is worse than that (I ran into it on x86-64 platform).
Reading config.h I see that ARCH_BIG_ENDIAN imply that ARCH_FLOAT_ENDIANNESS = 0x76543210
But, in both intern.c and extern.c the *serialize_block_8 and *serialize_float_8 functions use different conventions: the *block_8 functions perform a simple copy of their data when ARCH_BIG_ENDIAN is defined, whereas the *float_8 functions perform a simple copy when ARCH_FLOAT_ENDIANNESS is 0x01234567 (and therefor ARCH_BIG_ENDIAN is not defined).
So, maybe, double and other data are dealt with differently. In this case the issue is already solved, but it was triggered on any platforms. Or, there is an other typo in this code and the behaving of two of these functions should be exchanged between big and little endian (even though, it should now work consistently on one arch and even between big and little endian: only the old arm arch will be affected if the *_float_8 functions are faulty).
Let me try to resolve this old issue. It could be that (by mistake) the serialize_block_8 and serialize_float_8 functions use different conventions. However, as noted by Mathias Kende, they correctly read back data, even if it was written on a platform with a different endianness, which is the important property. Moreover, changing the conventions could be problematic for users who store persistent data in files or databases using output_value. So, I propose to leave the code as it is today and close this PR.
|2008-01-22 20:37||Mathias Kende||New Issue|
|2008-02-19 15:19||doligez||Status||new => acknowledged|
|2008-08-04 13:47||xleroy||Note Added: 0004562|
|2008-08-04 13:47||xleroy||Status||acknowledged => closed|
|2008-08-04 13:47||xleroy||Resolution||open => fixed|
|2008-09-23 18:52||Mathias Kende||Status||closed => feedback|
|2008-09-23 18:52||Mathias Kende||Resolution||fixed => reopened|
|2008-09-23 18:52||Mathias Kende||Note Added: 0004626|
|2009-04-01 18:39||xleroy||Assigned To||=> xleroy|
|2011-12-18 10:27||xleroy||Note Added: 0006370|
|2011-12-18 10:27||xleroy||Status||feedback => resolved|
|2011-12-18 10:27||xleroy||Resolution||reopened => no change required|
|2013-08-31 12:44||xleroy||Status||resolved => closed|
|Copyright © 2000 - 2011 MantisBT Group|