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 <avall...@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.stinckw...@gmail.com <mailto:serge.stinckw...@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." >> >> http://www.doesnotunderstand.org/ > >
