Hi All,

    currently the FFI has support for 8, 16, 32 & 64 bit integers, but no
support for C's long type.  In almost all C implementations byte is 8 bits,
short is 16 bits, int is 32 bits and long long is 64 bits.  But long may be
either 32 or 64 bits depending on programming model.

In LP32 long is 32 bits, which is used in 32-bit unix, mac os and windows.
In LP64 long is 64 bits, which is used in 64-bit unix and mac os.
In LLP64 long is 32 bits, which is used in 64-bit windows.

So having a type which is either 32 or 64 bits depending on platform is
useful in modeling C's long type across platforms.  Esteban and I propose
adding such a type to FFI kernel, actually two types, one unsigned, one
signed.  So we propose extending the below (these constants are used to
define signatures for FFI calls and the contents of structs)

FFIConstants class>>#initializeTypeConstants
"type void"
FFITypeVoid := 0.

"type bool"
FFITypeBool := 1.

"basic integer types.
note: (integerType anyMask: 1) = integerType isSigned"

FFITypeUnsignedByte := 2.
FFITypeSignedByte := 3.
FFITypeUnsignedShort := 4.
FFITypeSignedShort := 5.
FFITypeUnsignedInt := 6.
FFITypeSignedInt := 7.

"64bit types"
FFITypeUnsignedLongLong := 8.
FFITypeSignedLongLong := 9.

"special integer types"
FFITypeUnsignedChar := 10.
FFITypeSignedChar := 11.

"float types"
FFITypeSingleFloat := 12.
FFITypeDoubleFloat := 13.

"type flags"
FFIFlagAtomic := 16r40000. "type is atomic"
FFIFlagPointer := 16r20000. "type is pointer to base type"
FFIFlagStructure := 16r10000. "baseType is structure of 64k length"
FFIStructSizeMask := 16rFFFF. "mask for max size of structure"
FFIAtomicTypeMask := 16r0F000000. "mask for atomic type spec"
FFIAtomicTypeShift := 24. "shift for atomic type"

to add to
"special integer types"
FFITypeUnsignedChar := 10.
FFITypeSignedChar := 11.
FFITypePlatformUnsignedLong := 14.
FFITypePlatformSignedLong := 15.

This is backward compatible, even if it complicates the marshaling a little
since it used to be that all integer types were less than
FFITypeSingleFloat.  But breaking backward compatibility would be a bad
idea.

Then in ByteArray et al we could add accessors for platformLongAt:
platformUnsignedLongAt:.

Comments, thoughts, objections?
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20170119/68eb084f/attachment.html>