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;

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 "" >>>
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 "" >>> HPD>>>> Roland Turcan schrieb:
db>>

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

If you do not specify any "packrecords" setting, the compiler can do whatever it wants with the internal alignment of the record (and this can be different not only between different platforms, but also between different compiler versions). If you want a particular layout, use a particular packrecords setting ({$packrecords 1} with manual padding is probably the safest). See also http://wiki.freepascal.org/User_Changes_Trunk#Alignment_of_record_variables

One reason that it can be different on different platforms, is that the alignment of some types may be defined differently by the ABI (e.g., the Mac OS X/i386 ABI defines the alignment of double variables as 4 bytes, while on most other ABIs it's 8 bytes).

Jonas