Re: 'Image surprises.

Re: 'Image surprises.

[Stef Van Vlierberghe]

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