The compiler indeed inserted 32 dummy bits between the first (32 bits) and
second (64 bits) field. It feels like it want to align its 64 bits fields
on 64 bits chunk of bits because the 32 bits fields at the end of my
structure are contiguous.
Simply move the first 32 bits field at the end of the structure might sovle
it !
Thanks a lot for the quick response !!
2014-08-04 13:18 GMT+02:00 Igor Stasenko <siguc...@gmail.com>:
>
>
>
> On 4 August 2014 12:37, Thomas Bany <mun.sys...@gmail.com> wrote:
>
>> Hi everyone !
>>
>> I experience troubles with NBExternalStructure in NativeBoost when the
>> structure modeled contains fields with different types. For example,
>> manipulating the following structure poses no problem and I can manipulate
>> the fields correctly:
>>
>> typedef struct abc_s {
>> double a;
>> double b;
>> double c;
>> } abc;
>>
>> However, setting field 'a' to be an int yields the following symptoms:
>> ¤ From Pharo to C (function with 'abc' as argument type), the fields
>> are badly read.
>> ¤ From C to Pharo (function with 'abc' as return type), the VM crash
>> without an error nor a dump.
>>
>> Am I doing something wrong or is it maybe specific to the compiler I use
>> (the one that comes with Visual Studio Express 2013) ?
>>
>>
>>
> This caused by wrong alignment of structure in memory. Different compilers
> can align structures differently, and there's no way to know it at run time.
>
> Try to change the #
> *byteAlignment of the structure.Also, if nothing helps, you can use dummy
> fields* for padding fields, like in your example:
>
> int a;
> int dummy;
> double b;
> double c;
>
>
>> I'm pretty sure I could go arround this using NBExternalObject and
>> building the structure on C side, but it would be nice to avoid it.
>>
>>
>> On a side note, my understanding is that creating a structure on Pharo
>> side will have it stored in Pharo memory. Is it problematic when it comes
>> to pass it by value ? Or should I manage the copying on the C heap to be
>> safe ?
>>
>>
>> Thomas.
>>
>>
>
>
> --
> Best regards,
> Igor Stasenko.
>
