Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0004486OCamlOCaml generalpublic2008-01-22 20:372013-08-31 12:44
ReporterMathias Kende 
Assigned Toxleroy 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionno change required 
PlatformOSOS Version
Product Version3.10.0 
Target VersionFixed in Version 
Summary0004486: Bug with the serialization of double for custom value
DescriptionThe 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).
TagsNo tags attached.
Attached Files

- Relationships

-  Notes
(0004562)
xleroy (administrator)
2008-08-04 13:47

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.
(0004626)
Mathias Kende (reporter)
2008-09-23 18:52

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).
(0006370)
xleroy (administrator)
2011-12-18 10:27

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.

- Issue History
Date Modified Username Field Change
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
Powered by Mantis Bugtracker