frog
asked on
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?
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?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
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.
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.
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