Hello,
We attempted reading them bit by bit . We attempted giving 'packed' before records. We attempted giving --pack-struct . The last gave compilation errors and the first and the second are not all that simple to incorporate in the code because there are many types with records within records within records within records... Is there no way out other than to (vastly) change the code? BTW, Is implementation of the alignment-size-indication($Z) planned?
Thanks for the support , Regards, Anuradha
Frank Heckenbach wrote:
Anuradha wrote:
Hello,
Sorry for the last mail.We are resending it.
We have a problem as follows. We have a database file tabinfo.mdb created under WINDOWS using pervasive SQL(Btrieve).Now we are trying to access it with GPC. We fear that there is some allignment problem in the records stored and the record passed to read data out. The record we used to create the tabinfo in windows is :
MDB_MLTABL_TYPE = RECORD MLTABLNM : CHAR_8 ; RID : word ; LENPHYS : word ; PHYSINF : PH_ADDR ; EDITION : BYTE ; DATALEV : FS_FILE_TYPE ; MLTABDES : PH_ADDR ; ATTCOUNT : BYTE ; ATTINFO : ARRAY [ 1..MAX_ATTRIBS ] OF MDB_ATTR_INFO_TYPE ; RELFILES : ARRAY [ 1..MAX_RELFILES ] OF MDB_REL_FILE_TYPE ; END ;
We use the same record structure to read data back from it (but in GPC).But it doesnot read properly. Can you tell us why this happens? BTW, fs_file_type is a Enumerated type . ph_addr is longint. (We have given longint=int32 word=word16 in our program).
First of all, declare the record and the sub-arrays and sub-records (if any; I don't know what MDB_ATTR_INFO_TYPE etc. is) as `packed' (and be aware of the inefficiencies involved -- the first field seems to a a single byte, so the following fields will be at odd addresses which is clearly less efficient on IA32 and much less efficient on RISCs; I guess you don't have much choice here, but if you do serious processing, you might want to copy the data in/out of the packed structure).
Then check the sizes of each field, using `SizeOf', and use `Integer (n)' or `Cardinal(n)' in GPC for a type of size n bits.
For the enum field, you'll probably have to use `Cardinal(8)' (if the other compiler makes it 8 bits big), since otherwise GPC would pack it as small as possible (e.g., 4 bits if it has 9 .. 16 values).
Frank
-- Frank Heckenbach, frank@g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html
-- S.Anuradha Generic Data Tools, Alcatel Chennai. Alcanet : 2-757-7123
Anuradha wrote:
We attempted reading them bit by bit . We attempted giving 'packed' before records. We attempted giving --pack-struct . The last gave compilation errors and the first and the second are not all that simple to incorporate in the code because there are many types with records within records within records within records... Is there no way out other than to (vastly) change the code? BTW, Is implementation of the alignment-size-indication($Z) planned?
Please do not toppost - the result has been to lose all the context here.
Simply write one routine, whose purpose is to input that record (or a sequence of them) from the file. Write the routine in terms of sequential bytes. If you want to maintain backward compatibility write a corresponding output routine. You will have subroutines to take a particular sequence of bytes and convert to a particular type.
In general portable files should not be written as binary.