Cute! ;-)
So it seems this issue has arisen, because someone has decided to create 'getmemory' and 'freememory' routines, which simulate the functionality of 'new' and 'dispose' - strange!!! <g>
Nevertheless, I can't see any reason why the sample code presented should fail, unless there is also some issue with accessing of record fields and their address alignment, right?
Joe.
-----Original Message----- From: Frank Heckenbach [SMTP:frank@g-n-u.de] Sent: Friday, November 02, 2001 4:50 AM To: anuradha@adcc.alcatel.be; cbfalconer@worldnet.att.net; gpc@gnu.de Subject: Re: Re :Typecasting | record-field boundry
CBFalconer wrote:
Anuradha wrote:
The whole code is in a function 'getmemory' that 'getmem's the required number of bytes and stores the number of bytes in the previous 2 bytes. There is also a procedure 'freememory' that reads the previous 2 bytes and frees as many bytes as was allocated earlier by getmemory. what could be the problem ?
program typcast1; type Mytype=record i : integer; c:^char; end; var p:pointer; begin getmem(p,sizeof(mytype)+2); fillchar(p^,sizeof(mytype)+2,0); word(p^):=sizeof(mytype); p:=pchar(p)+2; mytype(p^).c:=nil; end.
Totally unneccessary. The system remembers the size allocated all by itself.
getmem(p, sizeneeded); operateon(p^); dispose(p); p := nil; (* safety measure *)
Pascal is a simple language. It doesn't have pointer arithmetic for very good reasons. Don't try to contort it into C.
(I believe. Certainly Pascalp operates this way, so does C, which supplies the underlying library for GPC. Frank can confirm or deny).
Confirm. Dispose and FreeMem are completely equivalent in GPC, and you even can omit the second parameter to FreeMem. So if you only need the extra memory for this purpose, you can avoid it entirely with GPC and replace getmemory by a simple GetMem.
And, of course, the 2 vs. 4 bytes issue looks quite much like the size of Integer, sso SizeOf (Integer) should work with both compilers. (Think about it: GPC allows memory allocations greater than 64 KB, so storing the size in 2 bytes is not a good idea. ;-)
Frank
-- Frank Heckenbach, frank@g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html
da Silva, Joe wrote:
So it seems this issue has arisen, because someone has decided to create 'getmemory' and 'freememory' routines, which simulate the functionality of 'new' and 'dispose' - strange!!! <g>
Not quite. In BP (which the code was originally written for AFAIUI), `New' does not support run-time variable sizes (there are no schema types or similar in BP). So every allocation of variable size has to be done via GetMem, and freed via FreeMem. Furthermore, BP does not keep track of the size allocated by itself, and FreeMem must be passed the correct size. So this stuff makes kind of sense for BP, but is quite unnecessary for GPC.
Nevertheless, I can't see any reason why the sample code presented should fail, unless there is also some issue with accessing of record fields and their address alignment, right?
Apart from the 2 vs. 4 bytes (i.e., SizeOf (Integer/Word/SizeType/...)) problem, there can be alignment problems. The Intel IA32 processors allow misaligned access, though with a speed penalty, other processors will simply crash.
With a "shift" of 2 bytes, you're sure to get alignment problems. With a shift of 4 bytes (as would be reasonable for GPC, see above), you might get problems with large types (LongInt, real types). Not sure what diffferent processors require, but I wouldn't be surprised if such code crashes on non-IA32 machines.
Frank
-
da Silva, Joe -
Frank Heckenbach