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, MSGID_SHORT autolearn=no autolearn_force=no version=3.4.4 Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!cs.utexas.edu!hellgate.utah.edu!dog.ee.lbl.gov!nosc!cod!sampson From: sampson@cod.NOSC.MIL (Charles H. Sampson) Newsgroups: comp.lang.ada Subject: Re: Default initialization and address clauses. Keywords: Ada, compiler, erroneous, address, initialization Message-ID: <2973@cod.NOSC.MIL> Date: 9 Apr 91 19:38:44 GMT References: <1991Apr8.174020.8176@software.org> Organization: Computer Sciences Corporation List-Id: In article <1991Apr8.174020.8176@software.org> smithd@software.org (Doug Smith) writes that he is violating the LRM, 13.5(8) by using address clauses to overlay data. He then questions some of the execution results he is get- ting, particularly when it comes to initializing these data. His question is: Can these data be reliably initialized as part of their declaration, or should they be initialized dynamically? To illustrate the problem, he gives two sim- ilar code fragments, of which the following is one. >with Text_IO; >with System; > >procedure Test is >begin > > Try_Access_Types: > declare > > type Pointer is access Integer; > > Pointer_Value : Pointer := new Integer; > Pointer_Value_2 : Pointer; -- Overlay !!! > for Pointer_Value_2 use at Pointer_Value'Address; > > begin > if Pointer_Value_2 = null then > Text_IO.Put_Line ("Your compiler initializes pointer " & > "declarations even with representation clauses."); > else > Text_IO.Put_Line ("Your compiler fails to initialize pointer " & > "declarations with representation clauses."); > end if; > end Try_Access_Types; > >end; His complaint is that this code executes differently on different compilers. The reason for the erratic behaviour is that the above code is erroneous, as Smith has pointed out, and the effect of executing erroneous code is un- predictable [LRM 1.6(7)]. Looking at the code, I would expect the generated code to first initialize Pointer_value, then initialize Pointer_value_2, overwriting Pointer_value's value with NULL, which is apparently what happens in most cases. However, wondrous things sometimes happen deep inside com- pilers, and the LRM doesn't require compiler writers to spend time on making sure that the obvious thing happens to erroneous programs. One possibility that comes to mind in this case is that some compilers accumulate blocks of static initial values out of line, and initialization begins by moving these blocks into position on the stack, followed by evalua- ting any non-static initial values. With this approach, Pointer_value_2's NULL is static and it will be overwritten after Pointer_value's allocator is evaluated. Charlie