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=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM
	autolearn=ham autolearn_force=no version=3.4.4
X-Google-Thread: 103376,6cbbf1799c1dc6da
X-Google-Attributes: gid103376,public
X-Google-Language: ENGLISH,ASCII
Path: 
 g2news1.google.com!news2.google.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: "Alex R. Mosteo" <devnull@mailinator.com>
Newsgroups: comp.lang.ada
Subject: Re: Ada 2005 box (<>) rules in default values
Date: Wed, 18 Jan 2006 12:04:47 +0100
Message-ID: <43CE20CF.4080801@mailinator.com>
References: <43CCAB76.6050907@mailinator.com>
 <T7dzf.154158$dP1.512644@newsc.telia.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Trace: individual.net NVYcCnfcyDfZFtVWsR/sZgEWGZQR9ei902N2SXofzCNxJke0c=
User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013)
X-Accept-Language: en-us, en
In-Reply-To: <T7dzf.154158$dP1.512644@newsc.telia.net>
Xref: g2news1.google.com comp.lang.ada:2518
Date: 2006-01-18T12:04:47+01:00
List-Id: <comp.lang.ada>

Bj�rn Persson wrote:

> This appears to be corrected in GCC 4.0.2 on Gnu/Linux, as it passes the 
> test below. Alex, could you please compile this program and verify that 
> it triggers the bug in your environment? If not, you might want to post 
> a compilable test case that does display the error.

I'm sorry the example I wrote was made up on the way. Upon reflexion, I 
think I always saw this problem in relation with Controlled types. 
Here's an example which fails with my current GPL:

with Ada.Text_IO; use Ada.Text_IO;
with Ada.Finalization; use Ada.Finalization;

procedure Bug2005 is

    type Thing is new Controlled with record
       First_Component  : Integer;
       Second_Component : Integer;
       Third_Component  : Integer;
    end record;

    procedure Initialize (This : in out Thing) is
    begin
       This.Third_Component := 5;
    end Initialize;

    type Superthing is record
       Innerthing : Thing;
    end record;

    Blah :          Superthing := (others => <>);
    Bleh :          Superthing;
    Blih : constant Superthing := (others => <>);
    Bloh : constant Superthing := (Innerthing => <>);
    Bluh : constant Superthing := (Innerthing =>
      (Controlled with others => <>));

begin
    Put_Line(": Blah.Innerthing.Third_Component = " &
      Integer'Image(Blah.Innerthing.Third_Component));
    Put_Line(": Bleh.Innerthing.Third_Component = " &
      Integer'Image(Bleh.Innerthing.Third_Component));
    Put_Line(": Blih.Innerthing.Third_Component = " &
      Integer'Image(Blih.Innerthing.Third_Component));
    Put_Line(": Bloh.Innerthing.Third_Component = " &
      Integer'Image(Bloh.Innerthing.Third_Component));
    Put_Line(": Bluh.Innerthing.Third_Component = " &
      Integer'Image(Bluh.Innerthing.Third_Component));
end Bug2005;

Execution:

$ gnatmake -gnat05 bug2005.adb
gcc -c -gnat05 bug2005.adb
gnatbind -x bug2005.ali
gnatlink bug2005.ali

$ ./bug2005
: Blah.Innerthing.Third_Component = -1208571208
: Bleh.Innerthing.Third_Component =  5
: Blih.Innerthing.Third_Component = -1208516512
: Bloh.Innerthing.Third_Component = -1208569267
: Bluh.Innerthing.Third_Component =  0

I think this is perhaps a different problem than the one I asked 
originally. But there's two things that make me think this is still an 
error, or at least a dangerous trap in the new Ada. In the link kindly 
provided by Mr. Brukardt I read (emphasis mine):

"if the component_declaration has a default_expression, that 
default_expression defines the value for the associated component(s); 
otherwise, the associated component(s) are initialized by default as for 
a *stand-alone object* of the component subtype (see 3.3.1)."

In a stand-alone object, as Bleh shows, the field would receive 
initialization.

Furthermore, if here Thing were a private type coming from elsewhere, I 
reasonably would expect that its default value were correct (I could in 
fact ignore that it is Controlled if this is declared in the private 
part of some package).

Indeed, this second case is the one that was biting me, with objects 
from the new standard container library.

Now I read in 7.6(10/2) (ARM05):

"During the elaboration or evaluation of a construct that causes an 
object to be initialized by default, for every controlled subcomponent 
of the object that is not assigned an initial value (as defined in 
3.3.1), Initialize is called on that subcomponent. Similarly, if the 
object that is initialized by default as a whole is controlled, 
Initialize is called on the object."

This justifies Bluh being wrong (and I agree, we are initializing 
explicitely the fields to default values in the type declaration, so 
Initialize doesn't get called. This comes from Ada95 already).

In the other cases, the controlled object is receiving default 
initialization as a whole, so I guess Initialize should be called? This 
certainly would take care of the "trap" I'm seeing here. The trap being 
that the implementer of a private controlled type should assure that a 
default object without suffering Initialization should be correct.

Your thoughts?