Le ven. 29 mai 2020 à 18:00, Nicolas Cellier <
nicolas.cellier.aka.nice at gmail.com> a écrit :

> And for your other question concerning the plugin:
>
> 1. it's been fixed only recently
> 2. it's not completely fixed with this regard!
>
> See ThreadedFFIPlugin>>checkAlignmentOfStructSpec:OfLength:StartingAt:
> We are always using the filedSize in case of atomic type as
> fieldAlignment...
> So it ain't gonna work for double/longlong/ulonglong on 32 bits linux
> (unless library is compiled with -malign-double or other exotic flags, but
> how could FFI guess that...)
> Ideally, the alignment would be occupying some bits in the type spec.
> Or we hardcode the well known exception in a second place.
> Anyway, the plugin also had to duplicate the alignment algorithm as you
> can see...
>
> We live in a world full of such accidental complexity...
> At least, while mankind is taking care of such detail, this leaves less
> time for killing each other, so let's declare that it's a good thing ;)
>
>
And that's the negative side of FFI: import the useless complexity inside
the image instead of burrying it under the VM carpet.
Exactly the same feeling as when I introduced the lineEnding zoo inside the
image instead of the simple CR.
It helps to play well in a complex world, but it's also importing
absolutely pointless complexity inside the image.
It's funny that we still pay such high a tribute to CR-LF for the decision
of a single person writing QDOS.
No matter that it was solved for long time by printcap/termcap unix
databases...
We are all adopting quick and dirty solutions from time to time, then
forget to think twice before distributing!

I still prefer having an opened platform to being lock in own autistic
world, but sometimes i wonder until which limit it is really worth...


Le ven. 29 mai 2020 à 17:37, Nicolas Cellier <
> nicolas.cellier.aka.nice at gmail.com> a écrit :
>
>> Found a 32bits debian VM:
>>
>> st at debi9:~$ gcc test_align.c
>> st at debi9:~$ ./a.out
>> size of x = 16
>> size of y = 16
>>
>> So keep the code, just correct it!
>>
>> Le ven. 29 mai 2020 à 17:01, Nicolas Cellier <
>> nicolas.cellier.aka.nice at gmail.com> a écrit :
>>
>>> Try with this:
>>>
>>> cat > test_align.c <<END
>>> #include <stdio.h>
>>>
>>> struct foo1 {int a; long long b; int d;};
>>> struct foo2 {int a; double c; int d;};
>>>
>>> int main() {
>>> struct foo1 x;
>>> struct foo2 y;
>>> printf("size of x = %d\n",sizeof(x));
>>> printf("size of y = %d\n",sizeof(y));
>>> return 0;
>>> }
>>> END
>>> i686-w64-mingw32-gcc test_align.c
>>>  ./a.exe
>>>
>>> size of x = 24
>>> size of y = 24
>>>
>>> so at leat in windows (mingw) the alignment is 8 bytes for both long
>>> long and double.
>>> I have no 32bits linux handy, but it should be easy enough to pass the
>>> same test...
>>>
>>> Le ven. 29 mai 2020 à 16:45, Nicolas Cellier <
>>> nicolas.cellier.aka.nice at gmail.com> a écrit :
>>>
>>>> Good catch!
>>>> Wikipedia page does not even agree on longlong... But it's not the
>>>> ultimate normative reference, better check by ourselves!
>>>> https://en.wikipedia.org/wiki/Data_structure_alignment
>>>>
>>>> Le ven. 29 mai 2020 à 15:53, Marcel Taeumel <marcel.taeumel at hpi.de> a
>>>> écrit :
>>>>
>>>>> Hi, there.
>>>>>
>>>>> In ExternalType class >> #initializeAtomicTypes, there is an
>>>>> interesting claim and a piece of dead code:
>>>>>
>>>>> "On 32 bits Windows and MacOS, double and long have an alignment of 8.
>>>>> But on Linux, their alignment is 4"
>>>>> (Smalltalk wordSize = 4 and: [Smalltalk platformName = 'unix'])
>>>>> ifTrue: [
>>>>> (#('double longlong ulonglong') includes: typeName) ifTrue: [
>>>>> byteAlignment := 4
>>>>> ]
>>>>> ].
>>>>>
>>>>> As you can see, there are single quotes missing and so will the path
>>>>> "byteAlignment  := 4" never be reached.
>>>>>
>>>>> I tried to figure out whether one should either fix the conditional or
>>>>> remove the entire passage. Maybe this got long fixed inside the FFI plugin?
>>>>>
>>>>> Best,
>>>>> Marcel
>>>>>
>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200529/c23e56f8/attachment.html>