signed long is now specified as: Capable of containing at least the [â2,147,483,647, +2,147,483,647] range; so at least 32 bits; and signed long long Capable of containing at least the [â9,223,372,036,854,775,807, +9,223,372,036,854,775,807] range [C99] so at least 64 bits; and long long size >= long size So a 32 bits long is legal, as well as a 64bits long, and as well as a 256bits long :) 2018-04-19 10:30 GMT+02:00 Andres Valloud <avalloud@smalltalk.comcastbiz.net>:
The relevant spec does not state 'long' is of any particular size.
On 4/19/18 1:24 , Serge Stinckwich wrote:
On Thu, Apr 19, 2018 at 9:13 AM, Serge Stinckwich <serge.stinckwich@gmail.com <mailto:serge.stinckwich@gmail.com>> wrote:
I try to understand differences between 32 bits and 64 bits FFI support for C structures.
I build a class called MyStruct subclass of FFIExternalStructure. and define a layout for this structure like this one :
MyStruct class>>fieldsDesc "self rebuildFieldAccessors"
^ #( int index ;)
and then I generate automatically the field accessors.
If I use a 32 bit VM, the following method is generated to access the index field :
index "This method was automatically generated" ^handle signedLongAt: OFFSET_INDEX
and if I use a 64 bits VM, the same method is generated ...
I'm a bit puzzled because, if sizeof(int) = sizeof(long) in a 32 bits VM, they have different for 64 bits VM (sizeof(int) = 4 and sizeof(long) = 8).
Someone to explain me or this is a bug ?
Ok I have understood ...
signedLongAt: method does not return a long as the name seems to indicate but in fact a 32 bits integer. So it works in both 32 and 64 bits VM.
Maybe signedInt32At: would have been a better name :-)
-- Serge Stinckwich UMI UMMISCO 209 (SU/IRD/UY1) "Programs must be written for people to read, and only incidentally for machines to execute."