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.li...@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 "k...@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 "drdiettri...@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 _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
