Calling C function via NLFFI binding may give result outside range of its C return type #272
Closed
2 of 12 tasks
Labels
bug
Something isn't working
fixed-in-110.99.4
issues that will be fixed in the 110.99.4 version
MLRISC
Issues in the MLRISC library
nlffigen
Version
110.99.3 (Latest)
Operating System
OS Version
Linux fedora 6.0.18-200.fc36.x86_64 #1 SMP PREEMPT_DYNAMIC Sat Jan 7 17:08:48 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
Processor
System Component
Foreign-Function Interface (FFI)
Severity
Minor
Description
For a C function whose return type is less than 32 bits, i.e. 8 or 16 bits, NLFFI generates bindings where the ML result type is
Int32.int
orWord32.word
. Although the ML type can represent a greater range of values than the C function returns, I would not expect the returned ML value to be outside the range of values that the C function can return. However, under certain conditions, the ML value is outside the range. The ML value is correct in the bits represented by the C function return type but higher bits may be 1, giving a value out of range. It appears that the code generated by NLFFI does not mask out the higher bits if a return type has fewer than 32 bits. The reason this can occur is because the value in the eax register is returned when only the value in the ax or al register is wanted.Transcript
The attached example produces the following output where the value of
c
is not in the range of anunsigned char
:Expected Behavior
In the transcript above, I would expect to see
Steps to Reproduce
The example nlffi-return-uchar-issue-20230309.tar.gz demonstrates this issue as follows:
In the output (see the transcript above) it can be seen that
c
has the value0wx100
which is outside the range of unsigned char. This behavior depends on how gcc compiles the functiongt
. For details, see the comments in the filetest-1.sml
.Note that the transcript above contains
I don't think this is related.
Additional Information
Here is the output from the my gdb session where I found the issue:
Email address
phil.clayton@veonix.com
The text was updated successfully, but these errors were encountered: