[fpc-pascal] RECORD alignment issue on Mac OS X intel based

[Roland Turcan]

Hello FPC-Pascal users discussions!

I am posting the same request to this mailing list and I posted into
lazarus.

Thanks for any answer in advance.

TRoland;

> Hello Dmitry,
>
> Thanks for your reply, but I think, that you haven't understood me
> what I am trying to explain.
>
> I have binary contents which are copied from memory using by an
> application which is written in Delphi. I am porting an application to
> MacOS X 10.5, but I need to use the same structures as I have in
> Delphi and Kylix where "NOT PACKED" records are aligned.
>
> The fact is, that FPC compiler on intel based Mac OS X builds up
> application which contains records "packed" by 4 bytes by default.
>
> I need to get the same behavior in intel based mac os x as I have in
> other platforms.
>
> What should I do to build FPC compiler which will behave the same on
> all platforms.
>
> TRoland;
>
> <<< 27.4.2009 17:04 - dmitry boyarintsev "skalogryz.lists at gmail.com" >>>
db>> use:
db>>   TYPE TMyOne = packed record
db>>               First:integer;
db>>               Second:extended;
db>>             END;
db>> to be sure about 20 bytes boundary.
>
db>> thanks,
db>> dmitry
>
>
db>> Hello All,
db>>
db>> I have found some new information about this problem:
db>>
db>> 1.
db>>
db>> TYPE TMyOne =record
db>>                First:integer;
db>>                Second:integer;
db>>              end;
db>>
db>> ... then the size of this object is 2*4 bytes.
db>>
db>> 2.
db>>
db>> TYPE TMyOne =record
db>>                First:integer;
db>>                Second:double;
db>>              END;
db>>
db>> ... where I would expect 4 + 8 bytes = 12 bytes
db>> ... but the size of this object is 16!
db>>
db>>
db>> 3.
db>>
db>> TYPE TMyOne =record
db>>                First:integer;
db>>                Second:extended;
db>>              END;
db>>
db>> ... where I would expect 4 + 16 bytes = 20 bytes
db>> ... but the size of this object is 32!
db>>
db>>
db>> So this proves me, that compiler tries to align the data structure to
db>> multiplied size of biggest element to which fit all elements.
db>>
db>> I have understood this behavior, but this happens me in these cases:
db>>
db>> 1. Delphi 7
db>> 2. Kylix 3
db>> 3. Lazarus on Ubuntu
db>> 4. Lazarus on PowerPC Mac OS X 10.5
db>>
db>> but on Intel Based Mac OS X 10.5 Mini with Intel Duo 2 Core it
db>> DOESN'T. Therefore I have problems with parsing of binaries back to
db>> memory.
db>>
db>> I don't expect CPU specific problem, otherwise it would not work
db>> active projects, therefore I think it must be compiler specific
db>> problem.
db>>
db>> Do you have any idea?
db>>
db>> Thanks in advance.
db>>
db>> Greetings, TRoland;
db>>
db>>
db>> <<< 25.4.2009 9:43 - Roland Turcan "konf at rotursoft.sk" >>>
RT>>> Hello Diettrich,
db>>
RT>>> To tell the truth this code and style I got from previous developer
RT>>> and I really don't know why he decided to get the size of header from
RT>>> the binary instead of getting its size. The fact is, that this
RT>>> "optimistic variant" of coding is on many places. :-|
db>>
RT>>> TRoland;
db>>
RT>>> <<< 24.4.2009 19:56 - Hans-Peter Diettrich "DrDiettrich1 at aol.com" >>>
HPD>>>> Roland Turcan schrieb:
db>>
>>>>> BB> How is HeaderLen declared ?
>>>>> 
>>>>> Stream.Read (HeaderLen, SIZEOF (HeaderLen));
>>>>> 
>>>>> where information header's length is stored into binary.
db>>
HPD>>>> The you should verify that HeaderLen <= SizeOf(FHeader), before
HPD>>>>    Stream.Read (FHeader, HeaderLen);
db>>
HPD>>>> Otherwise this statement will overwrite the following FItem data, with
HPD>>>> the fatal consequences you already experienced.
db>>
HPD>>>> When a header will ever change in size (or structure), it's wise to 
HPD>>>> store a version number in the data files. Then you can read the stored
HPD>>>> header data into the exactly applicable header type (record), and 
HPD>>>> convert that record into the current THeader definition, field by field.
db>>
HPD>>>> DoDi


-- 
Best regards, TRoland
http://www.rotursoft.sk
http://exekutor.rotursoft.sk