• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 340
  • Last Modified:

D3. Longints in a record

More in the saga of converting D1 to D3.
Under D1 a variable of type longint gave 32 bit fields in a record. Under D3 it does not. The original file of records created under D1 cannot be read under D3 when the type is longint or integer. If I cheat and declare the type as array[1..4] of char the actual data in the file cannot be read of course  but it is in sync where with the longint it slips out of sync, so I'm convinced that the longint is not allocating 4 bytes in the record.
How do I declare an integer type that is 32 bits long?  
0
frog
Asked:
frog
1 Solution
 
interCommented:
Hi,
This actually happens because of two facts. 1 - Integer to Integer incompatibility between 16 bit and 32 application 2 - usage of packed records.
1 - ABOUT 32bit integer formats
There are two formats called BIG ENDIAN and LITTLE ENDIAN when storing bitfields(I may mix one and other but the idea is as follows): Lets consider and example:
The big endian is the linear storage of the bytes from most significant to least significant. Thats what the human beigns expecs:
Longint = 5
Hex = $00000005
BIG END. = $00000005
LITTLE END $05000000
So the algorithm for converting big endian to little is
* Swap the high and low words
* then swap each byte in high and low words
So in general:
BIG END = $XXYYZZPP
LITTLE      = $PPZZYYXX
2 - ABOUT packed reserved word
if you declare the following in Delphi 2.0+ you see that it occupies 4 bytes instead of one
TByte = record
  x : byte;
end;
To make it occupy the correct size use
TByte = packed record
  x : byte;
end;
I think this is one cause to the problem
------
In short using longint in both D1 and D2+ with packed record should solve the problem. So declare your record as follows in both of the compilers
TMyRec = packed record
  x,y : longint;
end;
Regards, Igor
0
 
BlackManCommented:
Actually, LongInt is 32 bit long. I guess that your problem comes from a D2/D3 compilersetting, "Aligned record fields" (project options / compiler [code generation])
When this is checked, fields in a record are aligned at even adresses to make it faster for the CPU to fetch the data.  But this means, that there is a possibility of "extra" bytes in your record and that's why your recordstructure in memory is larger than the one (D1) on disk.
0
 
frogAuthor Commented:
Thanks BlackMan, that fixed it and will stop it happening again.

Inter your suggestion of packed record was the same thing of course. I'll post an empty question for you so you can answer and also get points.

I guess I need to find a FAQ on the differences between D1 and D3, the manual doesn't give any clues.

0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Free Tool: ZipGrep

ZipGrep is a utility that can list and search zip (.war, .ear, .jar, etc) archives for text patterns, without the need to extract the archive's contents.

One of a set of tools we're offering as a way to say thank you for being a part of the community.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now