Article View: comp.lang.modula2
Article #2404JPI Compiler bug?
From: Sean Wilson
Date: Thu, 21 Jan 1993 18:17
Date: Thu, 21 Jan 1993 18:17
105 lines
3418 bytes
3418 bytes
MO> Here`s a question for networked JPI-supporters:
MO> We tried to `overload` the NEW-procedure by implementing the module
MO> DEFINITION MODULE XStorage;
MO> FROM SYSTEM IMPORT ADDRESS;
MO> BEGIN
MO> ...
MO> PROCEDURE NEW ( VAR adr : ADDRESS );
MO> BEGIN
MO> ALLOCATE( adr, SIZE(adr^) );
MO> END NEW.
MO> END XStorage.
MO> Our intention was to avoid substituting NEW-calls in a number of source-MO> files by ALLOCATE() calls. This doesn`t work, because the compiler MO> allocates 4 bytes of memory, although the amount of x bytes, required MO> for the data structure adr points at, should be allocated, eg.
MO> TYPE
MO> RecordPtr = POINTER TO Record;
MO> Record = RECORD
MO> str : ARRAY [0..79] OF CHAR;
MO> int : INTEGER;
MO> END;
MO> XStorage.NEW( adr ) allocates 4 bytes of memory. An explicit MO> ALLOCATE()-call works.
MO> Got the point?
MO> Marcus
This isn't a compiler bug, overloading NEW() cannot be done in this way. When the compiler encounters a call to NEW() it will normally expand this to a call of the form:
ALLOCATE(adr, SIZE(adr^));
as you have determined. In order for this to work, the compiler must have information about the type of the variable in the NEW() call. This size information is not passed to your overloaded NEW().
The solution is to overload not the NEW() procedure but the ALLOCATE() and DEALLOCATE() procedures. Since these are not compiler generated you can be sure of getting all the relevant information, you can then do whatever you like in your own code. e.g:
DEFINITION MODULE XStorage;
PROCEDURE ALLOCATE(VAR adr: ADDRESS; len: CARDINAL);
PROCEDURE DEALLOCATE(VAR adr: ADDRESS; len: CARDINAL);
END XStorage.
IMPLEMENTATION MODULE XStorage;
IMPORT Storage;
PROCEDURE ALLOCATE(VAR adr: ADDRESS; len: CARDINAL);
BEGIN
(* ... *)
Storage.ALLOCATE(adr, len);
(* ... *)
END ALLOCATE;
PROCEDURE DEALLOCATE(VAR adr: ADDRESS; len: CARDINAL);
BEGIN
(* ... *)
Storage.DEALLOCATE(adr, len);
(* ... *)
END DEALLOCATE;
END XStorage.
MODULE Tst;
FROM XStorage IMPORT ALLOCATE, DEALLOCATE;
(* The above line replaces the following line in your code. *) (* FROM Storage IMPORT ALLOCATE, DEALLOCATE; *)
TYPE
RecordPtr = POINTER TO Record;
Record = RECORD
str : ARRAY [0..79] OF CHAR;
int : INTEGER;
END;
VAR
rec : RecordPtr;
BEGIN
(* In the following call the compiler still generates a call *)
(* to ALLOCATE, but this is resolved by XStorage.ALLOCATE *)
(* rather than Storage.ALLOCATE. *)
NEW(rec);
END Tst.
Best regards
Sean.
___
X PQ-Under-Trial 2.15 X If you ain't got it then you ain't communicatin'.
--
uucp: uunet!m2xenix!puddle!139!590!Sean.Wilson
Internet: Sean.Wilson@f590.n139.z1.fidonet.org
Technical Details
Message-ID:
<40647.2B5FB766@puddle.fidonet.org>Path:
arc1-ca.pugleaf.net!sparky!uunet!psgrain!puddle!f590.n139.z1.fidonet.org!Sean.WilsonShow Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!sparky!uunet!psgrain!puddle!f590.n139.z1.fidonet.org!Sean.Wilson From: Sean.Wilson@f590.n139.z1.fidonet.org (Sean Wilson) Sender: ufgate@puddle.fidonet.org (newsout1.26) Newsgroups: comp.lang.modula2 Subject: JPI Compiler bug? Message-ID: <40647.2B5FB766@puddle.fidonet.org> Date: Thu, 21 Jan 93 11:17:52 PDT Organization: FidoNet node 1:139/590 - PMI BBS, Green Bay WI Lines: 105