[Vm-dev] [OpenSmalltalk/opensmalltalk-vm] [SqueakFFIPrims] New integer primitives have issues with maxVal (#584)

[Marcel Taeumel]

In an FFI plugin that supports the new integer primitives, `maxVal` is wrong for unsigned types other than "uint8_t":

![grafik](https://user-images.githubusercontent.com/5765308/128748244-322f9952-c19c-4c8b-8970-290c38b04b2e.png)

This issue can be reproduced in any "FFI-Kernel" that supports those primitives such as "FFI-Kernel-mt.187" and newer:

```Smalltalk
#( int8_t uint8_t int16_t uint16_t int32_t uint32_t int64_t uint64_t ) 
collect: [:typeName | | type |
	type := ExternalType typeNamed: typeName.
	typeName -> (type minVal to: type maxVal)]
as: OrderedDictionary
```

**The older primitives "primitiveFFIIntegerAt" and "primitiveFFIIntegerAtPut" worked as expected.** The `maxVal` implementation writes single bytes but reads as much as the type demands. Here is an excerpt for the "unsigned" case:

```Smalltalk
| data bytes |
bytes := ByteArray new: self byteSize.
data := ExternalData fromHandle: bytes type: self size: 1.
	
bytes atAllPut: 16rFF. "Set all bits for maxVal of an unsigned integer. Uses older primitive 145."
^ data value. "-> ends up calling the new primitive in ByteArray such as uint16At:"
```

Note that "int8_t" and "uint8_t" work as expected.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/584
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20210809/feaa76e5/attachment.html>