From: stef@heron.cfmu.eurocontrol.be (Stef Van Vlierberghe)
Subject: Re: 'Image surprises.
Date: Thu, 8 Sep 1994 19:27:24 GMT
Date: 1994-09-08T19:27:24+00:00 [thread overview]
Message-ID: <STEF.94Sep8212725@heron.cfmu.eurocontrol.be> (raw)
In-Reply-To: Bob Wells #402's message of Fri, 2 Sep 1994 17:23:24 +0200
In article <9409021523.AA23134@eurocontrol.de> Bob Wells #402 <wel@EUROCONTROL.DE> writes:
Haven't got a Verdix compiler so I can only guess what happened, I included
some comments that might explain what a compiler might do :
declare -- 189/09
N_Data : Integer := 1;
-- not constant -> not static
type Dn_189_Data is array(1 .. N_Data) of Cs18909;
-- Doesn't necessarily understand that N_Data will be 1 at this point,
-- generated code might account for any N_Data, i.e. a possible 'SIZE
-- of gigabytes, use of a local heap to store it would be reasonable.
-- I wonder why this doesn't say 1..1, then this would definitely not
-- be on the heap if Cs18909 isn't.
-- I guess this is "inlined" generic code that wants the singleton array
-- to cover use with unconstrained discriminated types.
pragma Pack(Dn_189_Data);
Message_Type : Dn_189_Data;
-- This might be an object on the "local" heap, to be deallocated at some
-- scope exit (of the declare block or the innermost program unit, that's
-- up to the compiler I think).
for Message_Type use at P_Mesg_Conv(P_Ohead) + 12;
-- This is a rather tough command to the compiler. It might just interpret
-- this as "never-mind the heap, just assume Message_Type(1) is at
-- the specified address". But as the object is on the local heap, there may
-- be a larger-than-12 byte type descriptor in front of it, e.g. links to the
-- next and previous object on that heap.
-- It has always been my understanding that an address clause bypasses the
-- data allocation, but no "other" initialization, e.g. an access type obj
-- decl with address clause would still initialize that memory to null.
-- Similarly, the initialization of a local heap object might involve main-
-- taining the "to-be-freed-on-scope-exit" list, and hence this declaration
-- might fiddle with a few words *before* P_Ohead. No immediate damage done
-- to the Message_Type object (what a name for an object...), but if P_Ohead
-- was itself on the global heap, then that heap is now corrupt, the next
-- user that comes along may get hit...
-- I know this is far fetched, but it's the most likely I can think of.
-- Check in the debugger if this declaration messes with the memory before
-- or after the allocation designated by P_Ohead.
PFS_Test_Value : Integer := 0;
begin -- 189/09
PFS_Test_Value := Message_Type.Pfs;
-- No heap used yet, so this is still ok.
Text_Io.Put(" call sign has a PFS_Test_Value of");
Text_Io.Put_Line(Integer'Image(PFS_Test_Value));
-- Integer'Image is a function returning a string, and even though that string
-- is bound to fit in a "small" return object, the generated code might again
-- consider the general case and use the local heap (and indirectly the
-- global heap).
-- Perhaps you've seen the message from Robert Dewar how he envisages of getting
-- this done without using local heap and therefore imagine that the non-free
-- Ada compilers do even more sophisticated things... ;-)
Text_Io.Put(" call sign has a PFS number of");
Text_Io.Put_Line(Integer'Image(Message_Type.Pfs));
-- If my imagination above makes any sense, then this might indeed fail, and
-- there is not much more one can say about the state of things after a heap
-- corruption.
end;
Is the compiler wrong or am I missing something here (being late Friday and
all)? (-:
The LRM clearly defines the code above as erroneous [13.5(8)], so the
compiler cannot possible be wrong.
My advice is to abandon this dirty approach and use a method to encode/decode
your binary messages using a sequential I/O scheme such as the Streams in
Ada9X. Only preserve the current approach if you definitely can't live with
the increased runtime overhead. If you would choose to follow this advice
I can mail you some Eurocontrol proprietary sources that do such work, I don't
know about public domain implementations of such packages. Perhaps GNAT
contains some code you could steal^H^H^H^H^Hshare ?
Regards.
--
Stef VAN VLIERBERGHE Eurocontrol - CFMU room 12536
stef@cfmu.eurocontrol.be Raketstraat 96
Tel: +32 2 729 97 32 B-1030 BRUSSELS
Fax: +32 2 729 90 22 Belgium
--
Stef VAN VLIERBERGHE Eurocontrol - Central Flow Management Unit
stef@cfmu.eurocontrol.be Avenue des Arts 19H
Tel: +32 2 729 33 42 B-1040 BRUSSELS
Fax: +32 2 729 32 16 Belgium
parent reply other threads:[~1994-09-08 19:27 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <9409021523.AA23134@eurocontrol.de>]
replies disabled
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox