From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,771941d93f3c7138 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 1994-09-10 06:25:18 PST Newsgroups: comp.lang.ada Path: nntp.gmd.de!xlink.net!slsv6bt!slbh01.bln.sel.alcatel.de!rcvie!Austria.EU.net!newsfeed.ACO.net!swidir.switch.ch!univ-lyon1.fr!jussieu.fr!math.ohio-state.edu!howland.reston.ans.net!EU.net!ub4b!gate!cfmu!cfmu.eurocontrol.be!stef From: stef@heron.cfmu.eurocontrol.be (Stef Van Vlierberghe) Subject: Re: 'Image surprises. Sender: news@cfmu.eurocontrol.be (-) Message-ID: In-Reply-To: Bob Wells #402's message of Fri, 2 Sep 1994 17:23:24 +0200 Date: Thu, 8 Sep 1994 19:27:24 GMT References: <9409021523.AA23134@eurocontrol.de> Organization: Eurocontrol - Central Flow Management Unit Date: 1994-09-08T19:27:24+00:00 List-Id: In article <9409021523.AA23134@eurocontrol.de> Bob Wells #402 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