[Vm-dev] [OpenSmalltalk/opensmalltalk-vm] There is no bound check when marshalling FFI atomic integer arguments (#251)

[Nicolas Cellier]

We are talking about Foreign Function Interface, so we have to bear other's choice.
But we also can take full control. For this, we support 4 different FFI types:

- `sbyte` and `byte` if the intention is to handle 8 bit integer (signed and unsigned respectively)
- `schar` and `char` if the intention is to handle 8 bit character code (signed and unsigned respectively)

With those types, we can re-interpret precisely the intentions of external library thru our `<cdecl: returnType "function_prototype"(argType)>`  declarations. 

The question raised is more about changing the contract and making a Smalltalk module fail when it previously worked: such precise control was not always necessary in the past.

The main usage is (const char*), where the foreign expectation is receiving a NULL terminated string.
Since char is interpreted as unsigned by FFI - whatever the underlying machine/compiler dependent interpretation, and our character code are unsigned, the main usage should not be a problem.

Note that encoding has to be handled at an upper level, it's not explicitely described in FFI prototype, FFI is encoding-agnostic.

Note that we can pass a ByteString that will automatically be copied so as to have a NULL terminator.
Most ByteString are already Null terminated in Spur, unless their size is a multiple of 8, so we could optimize further and avoid a copy, but that's another subject.

-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/251#issuecomment-382371286
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20180418/1230fedc/attachment.html>