How many Ada compiler bugs are here?

How many Ada compiler bugs are here?

[Maciej Sobczak]

Consider:

with Ada.Finalization;
with Ada.Text_IO;

procedure Test is

   package P is
      Some_Error : exception;
      type T (<>) is limited private;
      function Make_T return T;
   private
      type T is new Ada.Finalization.Limited_Controlled with
         record
            Initialized : Boolean := False;
         end record;

      overriding procedure Adjust (V : in out T);
      overriding procedure Finalize (V : in out T);
   end P;

   package body P is
      function Make_T return T is
      begin
         raise Some_Error;

         --  needed to please the compiler:
         return (Ada.Finalization.Limited_Controlled
                   with others => <>);
      end Make_T;

      procedure Adjust (V : in out T) is
      begin
         Ada.Text_IO.Put_Line ("adjusting");
      end Adjust;

      procedure Finalize (V : in out T) is
      begin
         Ada.Text_IO.Put_Line
           ("finalizing with Initialized =" &
              Boolean'Image (V.Initialized));
      end Finalize;
   end P;

begin
   declare
      Tmp : P.T := P.Make_T;
   begin
      null;
   end;
exception
   when others =>
      Ada.Text_IO.Put_Line ("exception handled");
end Test;

This program prints (GNAT 2011):

$ ./test
finalizing with Initialized =TRUE
exception handled
$

Above:

1. Adjust should not be allowed to be declared (it is a *limited*
type). But I have defined it to trace the remaining bugs:
2. The return statement in Make_T should not be required, because it
is unreachable anyway.
3. Logically, Tmp is never created, because Make_T raises an
exception. Somehow some object is finalized. Apparently it is Tmp,
which should not exist.
4. Somehow Tmp.initialized = True, even though its default value is
defined to be False.

Guess how I found that out. It's past midnight here...

Are there any known workarounds?

--
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com

Re: How many Ada compiler bugs are here?

[Randy Brukardt]

"Maciej Sobczak" <see.my.homepage@gmail.com> wrote in message 
news:01dd6341-9c3c-4dcb-90f8-6ac66c65eb66@z1g2000vbx.googlegroups.com...
...
> 1. Adjust should not be allowed to be declared (it is a *limited*
> type). But I have defined it to trace the remaining bugs:

There's nothing wrong with defining "Adjust" (you can define any named 
subprogram you want, of course), but (A) "overriding" shouldn't be allowed 
on it, and (B) it shouldn't be called automatically if it is defined without 
"overriding", because it is not special for a limited type.

> 2. The return statement in Make_T should not be required, because it
> is unreachable anyway.

Ada requires all functions to have a return statement. 6.5(5/2). This was an 
Ada 83 rule; we've discussed removing it, but the feeling was that it 
catches as many errors as it creates, and we just couldn't justify a change 
to the language that didn't seem to be an obvious improvement. (In my 
personal work, it has been about 50-50 as to whether it helps or hinders.)

So the requirement for a return statement is not a bug, it's a language 
rule.

> 3. Logically, Tmp is never created, because Make_T raises an
> exception. Somehow some object is finalized. Apparently it is Tmp,
> which should not exist.
> 4. Somehow Tmp.initialized = True, even though its default value is
> defined to be False.

I'm not sure if these are actually bugs or not; the fact that Adjust is 
being called for a limited object means to me that nothing that happens 
afterwards makes any sense from a formal language perspective, so you can't 
really say if there is a bug. Garbage-in, garbage-out! Does the same thing 
happen without Adjust being defined? That would seem more like a bug.

                                                Randy.

Re: How many Ada compiler bugs are here?

[Adam Beneschan]

On Jan 12, 4:21 pm, "Randy Brukardt" <ra...@rrsoftware.com> wrote:

> > 2. The return statement in Make_T should not be required, because it
> > is unreachable anyway.
>
> Ada requires all functions to have a return statement. 6.5(5/2). This was an
> Ada 83 rule; we've discussed removing it, but the feeling was that it
> catches as many errors as it creates, and we just couldn't justify a change
> to the language that didn't seem to be an obvious improvement. (In my
> personal work, it has been about 50-50 as to whether it helps or hinders.)
>
> So the requirement for a return statement is not a bug, it's a language
> rule.

Maybe it would be helpful to remove the requirement for functions
whose last statement is a RAISE statement, so that stubs for functions
that aren't supposed to be called or aren't yet implemented don't have
to have the useless RETURN.  That way, you'd still catch most of the
errors that get caught by the rule, if not all of them.

I've written code where stub functions call some sort of error
procedure that performs a RAISE, and I would have to put a dummy
RETURN after the RAISE, which always annoyed me.  The change I
described wouldn't entirely fix that, since the function body ends
with a procedure call statement instead of a RAISE statement.  But at
least I could add a dummy "raise Program_Error;" at the end instead of
trying to write a return statement to cook up some value.

But then again, with extended returns, you don't need to cook up a
value.  The code:

         --  needed to please the compiler:
         return (Ada.Finalization.Limited_Controlled
                   with others => <>);

could be written more simply as

         return Dummy : T;

                                -- Adam





                          -- Adam


>
> > 3. Logically, Tmp is never created, because Make_T raises an
> > exception. Somehow some object is finalized. Apparently it is Tmp,
> > which should not exist.
> > 4. Somehow Tmp.initialized = True, even though its default value is
> > defined to be False.
>
> I'm not sure if these are actually bugs or not; the fact that Adjust is
> being called for a limited object means to me that nothing that happens
> afterwards makes any sense from a formal language perspective, so you can't
> really say if there is a bug. Garbage-in, garbage-out! Does the same thing
> happen without Adjust being defined? That would seem more like a bug.
>
>                                                 Randy.

Re: How many Ada compiler bugs are here?

[Dmitry A. Kazakov]

On Thu, 12 Jan 2012 17:26:34 -0800 (PST), Adam Beneschan wrote:

> But then again, with extended returns, you don't need to cook up a
> value.  The code:
> 
>          --  needed to please the compiler:
>          return (Ada.Finalization.Limited_Controlled
>                    with others => <>);
> 
> could be written more simply as
> 
>          return Dummy : T;

Not when T requires initialization, i.e. publicly has boxed discriminants.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: How many Ada compiler bugs are here?

[AdaMagica]

On 13 Jan., 09:23, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> On Thu, 12 Jan 2012 17:26:34 -0800 (PST), Adam Beneschan wrote:
> > But then again, with extended returns, you don't need to cook up a
> > value.  The code:
>
> >          --  needed to please the compiler:
> >          return (Ada.Finalization.Limited_Controlled
> >                    with others => <>);
>
> > could be written more simply as
>
> >          return Dummy : T;
>
> Not when T requires initialization, i.e. publicly has boxed discriminants.
>
> --
> Regards,
> Dmitry A. Kazakovhttp://www.dmitry-kazakov.de

Of course this is legal since it's in the scope of the full view (it's
a definite type in the full view, an indefinite only in the partial
view).

Re: How many Ada compiler bugs are here?

[Dmitry A. Kazakov]

On Fri, 13 Jan 2012 00:47:35 -0800 (PST), AdaMagica wrote:

> On 13 Jan., 09:23, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>> On Thu, 12 Jan 2012 17:26:34 -0800 (PST), Adam Beneschan wrote:
>>> But then again, with extended returns, you don't need to cook up a
>>> value. �The code:
>>
>>> � � � � �-- �needed to please the compiler:
>>> � � � � �return (Ada.Finalization.Limited_Controlled
>>> � � � � � � � � � �with others => <>);
>>
>>> could be written more simply as
>>
>>> � � � � �return Dummy : T;
>>
>> Not when T requires initialization, i.e. publicly has boxed discriminants.

> Of course this is legal since it's in the scope of the full view (it's
> a definite type in the full view, an indefinite only in the partial
> view).

Only if you have that full view in the function body.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: How many Ada compiler bugs are here?

[AdaMagica]

On 13 Jan., 10:07, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> On Fri, 13 Jan 2012 00:47:35 -0800 (PST), AdaMagica wrote:
> > On 13 Jan., 09:23, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> > wrote:
> >> On Thu, 12 Jan 2012 17:26:34 -0800 (PST), Adam Beneschan wrote:
> >>> But then again, with extended returns, you don't need to cook up a
> >>> value.  The code:
>
> >>>          --  needed to please the compiler:
> >>>          return (Ada.Finalization.Limited_Controlled
> >>>                    with others => <>);
>
> >>> could be written more simply as
>
> >>>          return Dummy : T;
>
> >> Not when T requires initialization, i.e. publicly has boxed discriminants.
> > Of course this is legal since it's in the scope of the full view (it's
> > a definite type in the full view, an indefinite only in the partial
> > view).
>
> Only if you have that full view in the function body.
>
> --
> Regards,
> Dmitry A. Kazakovhttp://www.dmitry-kazakov.de

What do you want to say? Isn't that exactly what I said?

Re: How many Ada compiler bugs are here?

[Dmitry A. Kazakov]

On Fri, 13 Jan 2012 01:35:58 -0800 (PST), AdaMagica wrote:

> On 13 Jan., 10:07, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>> On Fri, 13 Jan 2012 00:47:35 -0800 (PST), AdaMagica wrote:
>>> On 13 Jan., 09:23, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
>>> wrote:
>>>> On Thu, 12 Jan 2012 17:26:34 -0800 (PST), Adam Beneschan wrote:
>>>>> But then again, with extended returns, you don't need to cook up a
>>>>> value. �The code:
>>
>>>>> � � � � �-- �needed to please the compiler:
>>>>> � � � � �return (Ada.Finalization.Limited_Controlled
>>>>> � � � � � � � � � �with others => <>);
>>
>>>>> could be written more simply as
>>
>>>>> � � � � �return Dummy : T;
>>
>>>> Not when T requires initialization, i.e. publicly has boxed discriminants.
>>> Of course this is legal since it's in the scope of the full view (it's
>>> a definite type in the full view, an indefinite only in the partial
>>> view).
>>
>> Only if you have that full view in the function body.
>>
> What do you want to say? Isn't that exactly what I said?

package P is
   type T (<>) is private;
private
   type T is new Integer;
end P;

with P;  use P;
package Q is
   function Foo return T;
end Q;

package body Q is
   function Foo return T is
   begin
      raise Constraint_Error;
      return Dummy : T; -- No, that won't work!
   end Foo;
end Q;

The requirement to have a meaningless return might turn to be a serious
trouble. The example above might look constructed, but things like this
happen relatively frequently in large projects. And when they do, it forces
interfaces and package hierarchies reworked. Nasty thing.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: How many Ada compiler bugs are here?

[georg bauhaus]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote:

> 
> package P is
>    type T (<>) is private;
> private
>    type T is new Integer;
> end P;
> 
 
package P.Dummies is
   Meaningless_Dummy : constant T;
   Raising_Dummy : constant T;
private
   ...
End P.Dummies;

At project milestones, $ grep Dummies *.ad?
to see where finishing work is needed.

Re: How many Ada compiler bugs are here?

[Dmitry A. Kazakov]

On 13 Jan 2012 10:38:04 GMT, georg bauhaus wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote:
> 
>> 
>> package P is
>>    type T (<>) is private;
>> private
>>    type T is new Integer;
>> end P;
>> 
>  
> package P.Dummies is
>    Meaningless_Dummy : constant T;
>    Raising_Dummy : constant T;
> private
>    ...
> End P.Dummies;

Which of course defies the very idea of requiring T initialized. If there
exist some Meaningless_Dummy constant, then that could serve as an initial
value for T.

The whole point why Foo returning T raises an exception is that there NO
value to return!

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: How many Ada compiler bugs are here?

[Georg Bauhaus]

On 13.01.12 12:39, Dmitry A. Kazakov wrote:
> On 13 Jan 2012 10:38:04 GMT, georg bauhaus wrote:
> 
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote:
>>
>>>
>>> package P is
>>>    type T (<>) is private;
>>> private
>>>    type T is new Integer;
>>> end P;
>>>
>>  
>> package P.Dummies is
>>    Meaningless_Dummy : constant T;
>>    Raising_Dummy : constant T;
>> private
>>    ...
>> End P.Dummies;
> 
> Which of course defies the very idea of requiring T initialized. If there
> exist some Meaningless_Dummy constant, then that could serve as an initial
> value for T.

I'd drop Meaningless_Dummy, then, and declare only the dummy
that raises an exception:

package P is
   type T (<>) is private;
private
   type T is new Integer;
   function Raises_Assertion_Error return T;
end P;

package P.Dummies is
   Raising_Dummy : constant T;
private
   Raising_Dummy : constant T := Raises_Assertion_Error;
end P.Dummies;

-- or make Raising_Dummy a constructing function that raises,
-- so that raising happens where Raising_Dummy is written.

with Ada.Assertions;
package body P is
   function Raises_Assertion_Error return T is
      use Ada.Assertions;
   begin
      raise Assertion_Error with "FIXME";
      return Raises_Assertion_Error;
   end Raises_Assertion_Error;
end P;

Is this about statically ascertaining that a meaningful initial value
has been stored in an object of type T, where "meaningful" is a statically
known consequence of using some construction feature of non-Ada, or
not-yet-Ada?

Re: How many Ada compiler bugs are here?

[AdaMagica]

On 13 Jan., 13:43, Georg Bauhaus <rm.dash-bauh...@futureapps.de>
wrote:
> package P is
>    type T (<>) is private;
> private
>    type T is new Integer;
>    function Raises_Assertion_Error return T;
> end P;
>
> package P.Dummies is
>    Raising_Dummy : constant T;
> private
>    Raising_Dummy : constant T := Raises_Assertion_Error;
> end P.Dummies;
>
> -- or make Raising_Dummy a constructing function that raises,
> -- so that raising happens where Raising_Dummy is written.
>
> with Ada.Assertions;
> package body P is
>    function Raises_Assertion_Error return T is
>       use Ada.Assertions;
>    begin
>       raise Assertion_Error with "FIXME";
>       return Raises_Assertion_Error;
>    end Raises_Assertion_Error;
> end P;
>
> Is this about statically ascertaining that a meaningful initial value
> has been stored in an object of type T, where "meaningful" is a statically
> known consequence of using some construction feature of non-Ada, or
> not-yet-Ada?

I do not see what you are trying to accomplish. As written, P.Dummies
will raise an exception upon elaboration.

package P is
   type T (<>) is private;
   function F (...) return T;
private
  ...
end P;

This *is* the Ada way to force meaningful initial values. You may have
as many functions returning a T as you like with whatever parameter
profile. There is no need for any further apparatus. (Or am I missing
something?)

Re: How many Ada compiler bugs are here?

[AdaMagica]

Back to the title "How many Ada compiler bugs are here?"

I guess there's a countable infinity of mistakes. At any time, it's a
finite number, but whenever one is corrected, it's most probable that
a new one is introduced. And Ada is evolving, so implementations will
produce new mistakes.

I venture a wager that there is no compiler on earth that is error-
free (if the language it implements is elaborate enough so that you
would use it for some real project).

Re: How many Ada compiler bugs are here?

[Georg Bauhaus]

On 13.01.12 14:06, AdaMagica wrote:

>> package P.Dummies is
>>    Raising_Dummy : constant T;
>> private
>>    Raising_Dummy : constant T := Raises_Assertion_Error;
>> end P.Dummies;
>>
>> -- or make Raising_Dummy a constructing function that raises,
>> -- so that raising happens where Raising_Dummy is written.

> I do not see what you are trying to accomplish. As written, P.Dummies
> will raise an exception upon elaboration.

Yes, my head was spinning around objects that would
be (default) Initialized while my fingers were typing
something different. Hence the constant-turned-function
comment.

Re: How many Ada compiler bugs are here?

[Dmitry A. Kazakov]

On Fri, 13 Jan 2012 14:22:08 +0100, Georg Bauhaus wrote:

> Yes, my head was spinning around objects that would
> be (default) Initialized while my fingers were typing
> something different. Hence the constant-turned-function
> comment.

OT. In Ada values and functions are consistently interchangeable.

What you wanted is a lazy constant/value. I wonder is newly introduced
aspects for dereferencing could give you that effect. I am not sure.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: How many Ada compiler bugs are here?

[AdaMagica]

> >>> Of course this is legal since it's in the scope of the full view (it's
> >>> a definite type in the full view, an indefinite only in the partial
> >>> view).
>
> >> Only if you have that full view in the function body.
>
> > What do you want to say? Isn't that exactly what I said?
>
> package P is
>    type T (<>) is private;
> private
>    type T is new Integer;
> end P;

That's a severe design mistake. You cannot declare objects of T -
there are no constructors.

> with P;  use P;
> package Q is
>    function Foo return T;
> end Q;

You have to declare constructors in P (I know you know that, so why do
you write such nonsense?).

PS: I know that Foo in your terminology is not a constructor.

> package body Q is
>    function Foo return T is
>    begin
>       raise Constraint_Error;
>       return Dummy : T; -- No, that won't work!

So what? Yeah, that's not in the scope of the full view.

>    end Foo;
> end Q;
>
> The requirement to have a meaningless return might turn to be a serious
> trouble. The example above might look constructed, but things like this
> happen relatively frequently in large projects. And when they do, it forces
> interfaces and package hierarchies reworked. Nasty thing.

Well, yes, design errors happen. Everyone knows that...

But this example is a silly mistake. You know that.

Re: How many Ada compiler bugs are here?

[Dmitry A. Kazakov]

On Fri, 13 Jan 2012 02:52:29 -0800 (PST), AdaMagica wrote:

>>>>> Of course this is legal since it's in the scope of the full view (it's
>>>>> a definite type in the full view, an indefinite only in the partial
>>>>> view).
>>
>>>> Only if you have that full view in the function body.
>>
>>> What do you want to say? Isn't that exactly what I said?
>>
>> package P is
>> � �type T (<>) is private;
>> private
>> � �type T is new Integer;
>> end P;
> 
> That's a severe design mistake. You cannot declare objects of T -
> there are no constructors.

P could have a constructing function, but that would not make the return
statement in Q legal.

Note, my point was that the workaround Adam suggested does not always work
in the real-life code.

>> The requirement to have a meaningless return might turn to be a serious
>> trouble. The example above might look constructed, but things like this
>> happen relatively frequently in large projects. And when they do, it forces
>> interfaces and package hierarchies reworked. Nasty thing.
> 
> Well, yes, design errors happen. Everyone knows that...

An unreachable return required by the language is certainly a design error.
But I suggest that you are rather trying to excuse Ada's sloppiness in this
issue. If they wanted to be adamant on requiring return, they should have
allowed raising return, e.g.

   function Foo return T is
   begin
      return raise Constraint_Error;
   end Foo;

> But this example is a silly mistake. You know that.

Where do you see any mistake? I omitted constructing functions because,
firstly, they are irrelevant to the point I am making, and, secondly,
because factories could be provided by other packages, not necessarily by P
itself.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: How many Ada compiler bugs are here?

[AdaMagica]

On 13 Jan., 12:35, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> An unreachable return required by the language is certainly a design error.

Well, yes, you may see this as such. But it's not a severe one, or
else the ARG would certainly have changed that.

> But I suggest that you are rather trying to excuse Ada's sloppiness in this
> issue.

Ada's not perfect, we all know that. But it's one of the best...

> > But this example is a silly mistake. You know that.
>
> Where do you see any mistake? I omitted constructing functions because,
> firstly, they are irrelevant

they're not, see below

> to the point I am making, and, secondly,
> because factories could be provided by other packages, not necessarily by P
> itself.

But without a constructor in P (or in children thereof) for T there
cannot be any factories anywhere. This is silly mistake in your
example.

Re: How many Ada compiler bugs are here?

[Dmitry A. Kazakov]

On Fri, 13 Jan 2012 04:58:21 -0800 (PST), AdaMagica wrote:

> On 13 Jan., 12:35, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:

>> But I suggest that you are rather trying to excuse Ada's sloppiness in this
>> issue.
> 
> Ada's not perfect, we all know that. But it's one of the best...

The best, IMO.

>> to the point I am making, and, secondly,
>> because factories could be provided by other packages, not necessarily by P
>> itself.
> 
> But without a constructor in P (or in children thereof) for T there
> cannot be any factories anywhere. This is silly mistake in your
> example.

No. You can have them in children packages, which is not so uncommon to do. 

I ran into the issue of required return statement several times. If you
have a hierarchy of managed objects, for which you would like to prevent
stack instances or make them accessible only though proxy objects, etc.
Especially when some fields are not null access. Then you may get this
problem. It can occur pretty late and require a huge amount of redesign.
Because to access the full view the package must be a child, and it is
usually already a child of some other package and not without a reason,
e.g. to access the internals of those.

BTW, I always wondered why cannot we have multiple parents of a package in
Ada?

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: How many Ada compiler bugs are here?

[Robert A Duff]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> No. You can have them in children packages, which is not so uncommon to do. 

True.  You could also create all the objects (maybe there is only one!)
in the body of package P itself, and perhaps hand out access-to-T values.

> I ran into the issue of required return statement several times. If you
> have a hierarchy of managed objects, for which you would like to prevent
> stack instances or make them accessible only though proxy objects, etc.
> Especially when some fields are not null access. Then you may get this
> problem. It can occur pretty late and require a huge amount of redesign.

I don't think it can cause huge redesign.  I agree with you that it's a
language design flaw, but I also agree with AdaMagica that it's a small
one.  Here's a workaround:

   function Foo return T is
   begin
      raise Constraint_Error;
      return Foo; -- kludgy recursive call; can't get here!
   end Foo;

If Foo takes parameters, pass them along in the recursive call.
No need to gin up a value of type T.

> BTW, I always wondered why cannot we have multiple parents of a package in
> Ada?

Sounds hugely complicated.

- Bob

Re: How many Ada compiler bugs are here?

[Dmitry A. Kazakov]

On Fri, 13 Jan 2012 10:06:02 -0500, Robert A Duff wrote:

> Here's a workaround:
> 
>    function Foo return T is
>    begin
>       raise Constraint_Error;
>       return Foo; -- kludgy recursive call; can't get here!
>    end Foo;

Cool! I never thought about that. Thanks!
 
>> BTW, I always wondered why cannot we have multiple parents of a package in
>> Ada?
> 
> Sounds hugely complicated.

Why? The only complicated thing would naming of the files.

Instantiation of multiple parent's generic child must be fun, but no more
than generic child already is.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: How many Ada compiler bugs are here?

[georg bauhaus]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote:
> On Fri, 13 Jan 2012 10:06:02 -0500, Robert A Duff wrote:
> 
>> Here's a workaround:
>> 
>>    function Foo return T is
>>    begin
>>       raise Constraint_Error;
>>       return Foo; -- kludgy recursive call; can't get here!
>>    end Foo;
> 
> Cool! I never thought about that. Thanks!

Have you used gnatstub before?

Re: How many Ada compiler bugs are here?

[Dmitry A. Kazakov]

On 13 Jan 2012 17:42:57 GMT, georg bauhaus wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote:
>> On Fri, 13 Jan 2012 10:06:02 -0500, Robert A Duff wrote:
>> 
>>> Here's a workaround:
>>> 
>>>    function Foo return T is
>>>    begin
>>>       raise Constraint_Error;
>>>       return Foo; -- kludgy recursive call; can't get here!
>>>    end Foo;
>> 
>> Cool! I never thought about that. Thanks!
> 
> Have you used gnatstub before?

Never. I always add a specification and the body together, i.e.

   spec A
   body A
   spec B
   body B
   ...

rather than

   spec A
   spec B
   ...
   body A
   body B
   ...

Otherwise I would certainly forget to implement something, because I do not
do coverage testing.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: How many Ada compiler bugs are here?

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:11extopcf5hsy.qk7psu30kjrp.dlg@40tude.net...
>>> BTW, I always wondered why cannot we have multiple parents of a package 
>>> in
>>> Ada?
>>
>> Sounds hugely complicated.
>
> Why? The only complicated thing would naming of the files.

Because the parent's declarations are directly visible in the child. If 
there are multiple parents, you'd have multiple scopes of declarations 
directly visible, and we would have to worry about what happens when there 
are conflicts. We don't have to do this in Ada today.

There is a similar problem for package use clauses, but there is no 
satisfactory solution to that problem. All of the solutions are dangerous 
(Ada picks the least dangerous solution, but it still has lots of issues in 
practice). I don't think we want more of these cases.

In fact, the only *safe* alternative is for there to be precisely one scope 
that is directly visible. This isn't very practical, I'm afraid, and I don't 
know of any way to support that for children.

[Aside: I'm now convinced that the primary problem with use clauses is 
conflicts between non-overloadable entities. As such, "use type" and "use 
all type" are much safer (since they only make overloadable entities 
visible), and I will be using them more often in new code. I'm still going 
to avoid package use in the vast majority of cases.]

I realize that allowing only one of something is always going to be a 
problem: one parent, one stream attribute of each kind, etc. But many of 
these defy easy solution.

                                                        Randy.

Re: How many Ada compiler bugs are here?

[Dmitry A. Kazakov]

On Fri, 13 Jan 2012 18:26:13 -0600, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:11extopcf5hsy.qk7psu30kjrp.dlg@40tude.net...
>>>> BTW, I always wondered why cannot we have multiple parents of a package 
>>>> in Ada?
>>>
>>> Sounds hugely complicated.
>>
>> Why? The only complicated thing would naming of the files.
> 
> Because the parent's declarations are directly visible in the child. If 
> there are multiple parents, you'd have multiple scopes of declarations 
> directly visible, and we would have to worry about what happens when there 
> are conflicts. We don't have to do this in Ada today.

Yes, but I want this feature in other form anyway. I want to have an
ability to fuse several declaration scopes into a package to reuse obtained
direct visibility scope later. It is quite a problem now that packages need
large sets of "with" and "use" clauses in front of them as well as multiple
"use" clauses inside them (for generic instances). This stuff is repeated
over and over again, which is a maintenance problem and a problem for the
reader.

> There is a similar problem for package use clauses, but there is no 
> satisfactory solution to that problem. All of the solutions are dangerous 
> (Ada picks the least dangerous solution, but it still has lots of issues in 
> practice). I don't think we want more of these cases.

I am not sure which solutions you have in mind. I would simply forbid any
conflicts. The compiler must insist on explicit renaming of all conflicting
entities.

It is rather a perceived problem so long declaration scopes cannot be named
an reused. Once we would use them as named entities, construct and design
them intentionally, the problem would disappear.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: How many Ada compiler bugs are here?

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:e8vqwjo7ify3.htkn2p8qs8lw$.dlg@40tude.net...
> On Fri, 13 Jan 2012 18:26:13 -0600, Randy Brukardt wrote:
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>> news:11extopcf5hsy.qk7psu30kjrp.dlg@40tude.net...
>>>>> BTW, I always wondered why cannot we have multiple parents of a 
>>>>> package
>>>>> in Ada?
>>>>
>>>> Sounds hugely complicated.
>>>
>>> Why? The only complicated thing would naming of the files.
>>
>> Because the parent's declarations are directly visible in the child. If
>> there are multiple parents, you'd have multiple scopes of declarations
>> directly visible, and we would have to worry about what happens when 
>> there
>> are conflicts. We don't have to do this in Ada today.
>
> Yes, but I want this feature in other form anyway. I want to have an
> ability to fuse several declaration scopes into a package to reuse 
> obtained
> direct visibility scope later. It is quite a problem now that packages 
> need
> large sets of "with" and "use" clauses in front of them as well as 
> multiple
> "use" clauses inside them (for generic instances). This stuff is repeated
> over and over again, which is a maintenance problem and a problem for the
> reader.

I agree with you, and in fact we tried to provide such a feature in Ada 
2012. (See AI05-0135-2.) We eventually gave up, mainly because any scheme 
for managing the conflicts caused unacceptable problems in maintenance.

>> There is a similar problem for package use clauses, but there is no
>> satisfactory solution to that problem. All of the solutions are dangerous
>> (Ada picks the least dangerous solution, but it still has lots of issues 
>> in
>> practice). I don't think we want more of these cases.
>
> I am not sure which solutions you have in mind. I would simply forbid any
> conflicts. The compiler must insist on explicit renaming of all 
> conflicting
> entities.

We tried rules on that line, but they caused the sorts of maintenance 
problems that aren't really acceptable. It should never be the case that 
adding a declaration to a package makes some other package illegal even 
though the other package does not use the new declaration. (Yes, I know 
there are cases where direct visibility and parent visibility violate this 
principle, but just because the language is already wrong doesn't mean it 
should be made wronger. :-)
[Keep in mind I'm talking about an *addition* and not a modification of a 
declaration. The principle is that adding new features to a package 
shouldn't cause clients that don't use those features to need modification.]

Another cause of problems was diamond inheritance, where an integrated 
package tries to add a declaration that is already directly visible by some 
other path. We definitely don't want those to conflict, but it is very hard 
to craft rules that have the right effect (in large part because visibility 
is based on "views", not "entities", and these clearly are different views).

> It is rather a perceived problem so long declaration scopes cannot be 
> named
> an reused. Once we would use them as named entities, construct and design
> them intentionally, the problem would disappear.

Maybe, but the evidence is that handling the conflicts is a major 
maintenance problem.

One thing that clearly would help would be to make all entities 
overloadable. In that case, there would be far fewer conflicts (objects 
would overload on their types, and could overload with functions and 
procedures as well), so perhaps we could live with the conflicts. But that 
would be hugely expensive in existing Ada compilers (pretty much all of the 
visibility mechanisms would have to be redone from scratch), and it is 
unlikely that it could be done compatibly with existing code.

I made a proposal to allow overloading of objects (only), which I believe 
could in fact be done compatibly, but it went nowhere. And there still would 
be problems with exceptions and packages and types (none of which can be 
overloaded currently or in any compatible way), so its probably not enough.

                                    Randy.

Re: How many Ada compiler bugs are here?

[Dmitry A. Kazakov]

On Wed, 18 Jan 2012 19:35:39 -0600, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:e8vqwjo7ify3.htkn2p8qs8lw$.dlg@40tude.net...
>> On Fri, 13 Jan 2012 18:26:13 -0600, Randy Brukardt wrote:
>>
>>> There is a similar problem for package use clauses, but there is no
>>> satisfactory solution to that problem. All of the solutions are dangerous
>>> (Ada picks the least dangerous solution, but it still has lots of issues in
>>> practice). I don't think we want more of these cases.
>>
>> I am not sure which solutions you have in mind. I would simply forbid any
>> conflicts. The compiler must insist on explicit renaming of all 
>> conflicting entities.
> 
> We tried rules on that line, but they caused the sorts of maintenance 
> problems that aren't really acceptable. It should never be the case that 
> adding a declaration to a package makes some other package illegal even 
> though the other package does not use the new declaration. (Yes, I know 
> there are cases where direct visibility and parent visibility violate this 
> principle, but just because the language is already wrong doesn't mean it 
> should be made wronger. :-)
> [Keep in mind I'm talking about an *addition* and not a modification of a 
> declaration. The principle is that adding new features to a package 
> shouldn't cause clients that don't use those features to need modification.]

This goal is unreachable in principle. It is the same delusion as behind
the LSP. There is not such thing as safe extension or addition, alas. That
should not hinder use of addition (in either form of a subtype or an
extended package).

> Another cause of problems was diamond inheritance, where an integrated 
> package tries to add a declaration that is already directly visible by some 
> other path. We definitely don't want those to conflict, but it is very hard 
> to craft rules that have the right effect (in large part because visibility 
> is based on "views", not "entities", and these clearly are different views).

Yep, that must be fixed. It must be clear where the semantics is
referential and where it is not. Presently it is so as if there were no
difference, but this concept is clearly not maintainable anymore.

>> It is rather a perceived problem so long declaration scopes cannot be named
>> an reused. Once we would use them as named entities, construct and design
>> them intentionally, the problem would disappear.
> 
> Maybe, but the evidence is that handling the conflicts is a major 
> maintenance problem.

Right, that is why we have to address this. In particular to flag conflicts
as errors rather than letting them slipping through the layers of packages
to the point where there is no easy way to fix the problem. Early error
detection is the Ada's strength.

If we had means to design declaration scopes, then instead of patching
conflicting packages, we could create an integration package which would
resolve conflicts and use that package instead of both.

> One thing that clearly would help would be to make all entities 
> overloadable. In that case, there would be far fewer conflicts (objects 
> would overload on their types, and could overload with functions and 
> procedures as well), so perhaps we could live with the conflicts. But that 
> would be hugely expensive in existing Ada compilers (pretty much all of the 
> visibility mechanisms would have to be redone from scratch), and it is 
> unlikely that it could be done compatibly with existing code.

We, the programmers, do not care. That is your problem! (:-))

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: How many Ada compiler bugs are here?

[Robert A Duff]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> Cool! I never thought about that. Thanks!

You're welcome!

>>> BTW, I always wondered why cannot we have multiple parents of a package in
>>> Ada?
>> 
>> Sounds hugely complicated.
>
> Why? The only complicated thing would naming of the files.

Tree structures are easier to understand than more-complicated graphs.

I think it would make the visibility rules more complicated
for users (and harder to implement).

I'm not sure how to deal with private vs. public children.

Probably other stuff I haven't thought of.
Isn't Ada 2012 complicated enough?  ;-)

> Instantiation of multiple parent's generic child must be fun, but no more
> than generic child already is.

Yeah, well, generics multiply the complexity of anything
they interact with.

- Bob

Re: How many Ada compiler bugs are here?

[Adam Beneschan]

On Jan 13, 2:00 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> On Fri, 13 Jan 2012 01:35:58 -0800 (PST), AdaMagica wrote:
> > On 13 Jan., 10:07, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> > wrote:
> >> On Fri, 13 Jan 2012 00:47:35 -0800 (PST), AdaMagica wrote:
> >>> On 13 Jan., 09:23, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> >>> wrote:
> >>>> On Thu, 12 Jan 2012 17:26:34 -0800 (PST), Adam Beneschan wrote:
> >>>>> But then again, with extended returns, you don't need to cook up a
> >>>>> value.  The code:
>
> >>>>>          --  needed to please the compiler:
> >>>>>          return (Ada.Finalization.Limited_Controlled
> >>>>>                    with others => <>);
>
> >>>>> could be written more simply as
>
> >>>>>          return Dummy : T;
>
> >>>> Not when T requires initialization, i.e. publicly has boxed discriminants.
> >>> Of course this is legal since it's in the scope of the full view (it's
> >>> a definite type in the full view, an indefinite only in the partial
> >>> view).
>
> >> Only if you have that full view in the function body.
>
> > What do you want to say? Isn't that exactly what I said?
>
> package P is
>    type T (<>) is private;
> private
>    type T is new Integer;
> end P;
>
> with P;  use P;
> package Q is
>    function Foo return T;
> end Q;
>
> package body Q is
>    function Foo return T is
>    begin
>       raise Constraint_Error;
>       return Dummy : T; -- No, that won't work!
>    end Foo;
> end Q;
>
> The requirement to have a meaningless return might turn to be a serious
> trouble. The example above might look constructed, but things like this
> happen relatively frequently in large projects. And when they do, it forces
> interfaces and package hierarchies reworked. Nasty thing.

I think that most likely, if I had a package P that declared a type
like this, it would also declare some function (or a deferred
constant) to represent some sort of "empty" or "null" or "undefined"
value.  I guess one could come up with a case where it wouldn't be
needed, but I haven't come across one; in my experience, it's *always*
been useful to have a value like that that can be used by users of the
package.  Anyway, having something like that would make the problem
moot, in your example.

                      -- Adam

Re: How many Ada compiler bugs are here?

[Robert A Duff]

Adam Beneschan <adam@irvine.com> writes:

> I think that most likely, if I had a package P that declared a type
> like this, it would also declare some function (or a deferred
> constant) to represent some sort of "empty" or "null" or "undefined"
> value.

Have you read "The Billion Dollar Mistake", by C.A.R. Hoare?

- Bob

Re: How many Ada compiler bugs are here?

[Adam Beneschan]

On Jan 13, 12:23 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> On Thu, 12 Jan 2012 17:26:34 -0800 (PST), Adam Beneschan wrote:
> > But then again, with extended returns, you don't need to cook up a
> > value.  The code:
>
> >          --  needed to please the compiler:
> >          return (Ada.Finalization.Limited_Controlled
> >                    with others => <>);
>
> > could be written more simply as
>
> >          return Dummy : T;
>
> Not when T requires initialization, i.e. publicly has boxed discriminants.

Or if T is any other indefinite type, such as an unconstrained array
(including String) or a classwide type.

                    -- Adam

Re: How many Ada compiler bugs are here?

[Blady]

On 13 jan, 01:21, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
> "Maciej Sobczak" <see.my.homep...@gmail.com> wrote in message
>
> news:01dd6341-9c3c-4dcb-90f8-6ac66c65eb66@z1g2000vbx.googlegroups.com...
> ...
>
> > 1. Adjust should not be allowed to be declared (it is a *limited*
> > type). But I have defined it to trace the remaining bugs:
>
> There's nothing wrong with defining "Adjust" (you can define any named
> subprogram you want, of course), but (A) "overriding" shouldn't be allowed
> on it, and (B) it shouldn't be called automatically if it is defined without
> "overriding", because it is not special for a limited type.
>
8< ... >8
>
>                                                 Randy.

Hello,
back to point 1), assuming GNAT is used, the private spec of
Ada.Finalization is
   package SFR renames System.Finalization_Root;
   type Controlled is abstract new SFR.Root_Controlled with null
record;
   --  In order to simplify the implementation, the mechanism in
Process_Full_
   --  View ensures that the full view is limited even though the
parent type
   --  is not.
   type Limited_Controlled is
     abstract new SFR.Root_Controlled with null record;
and
   type Root_Controlled is tagged null record;
   procedure Adjust     (Object : in out Root_Controlled);
   procedure Finalize   (Object : in out Root_Controlled);
   procedure Initialize (Object : in out Root_Controlled);
So with GNAT Adjust is part of Limited_Controlled primitives, isn't
it?

Best, Pascal.

Re: How many Ada compiler bugs are here?

[Adam Beneschan]

On Jan 13, 12:06 pm, Blady <p....@orange.fr> wrote:
>
> > > 1. Adjust should not be allowed to be declared (it is a *limited*
> > > type). But I have defined it to trace the remaining bugs:
>
> > There's nothing wrong with defining "Adjust" (you can define any named
> > subprogram you want, of course), but (A) "overriding" shouldn't be allowed
> > on it, and (B) it shouldn't be called automatically if it is defined without
> > "overriding", because it is not special for a limited type.

> Hello,
> back to point 1), assuming GNAT is used, the private spec of
> Ada.Finalization is
>    package SFR renames System.Finalization_Root;
>    type Controlled is abstract new SFR.Root_Controlled with null
> record;
>    --  In order to simplify the implementation, the mechanism in
> Process_Full_
>    --  View ensures that the full view is limited even though the
> parent type
>    --  is not.
>    type Limited_Controlled is
>      abstract new SFR.Root_Controlled with null record;
> and
>    type Root_Controlled is tagged null record;
>    procedure Adjust     (Object : in out Root_Controlled);
>    procedure Finalize   (Object : in out Root_Controlled);
>    procedure Initialize (Object : in out Root_Controlled);
> So with GNAT Adjust is part of Limited_Controlled primitives, isn't
> it?
>
> Best, Pascal.

Since Limited_Controlled is derived from SFR.Root_Controlled in the
*private* part of Ada.Finalization, any primitive operations that get
inherited shouldn't be visible to any place that can't see the private
part of Ada.Finalization; and therefore this should not affect the
legality of anything.  Maciej's package says

  overriding procedure Adjust (...)

which is illegal because Adjust isn't supposed to be visible to his
package.  If GNAT is accepting this, this means that some stuff that
should be invisible is visible, and that's a bug.

                              -- Adam

Re: How many Ada compiler bugs are here?

[Brian Drummond]

On Fri, 13 Jan 2012 15:30:37 -0800, Adam Beneschan wrote:

> Maciej's package says
> 
>   overriding procedure Adjust (...)
> 
> which is illegal because Adjust isn't supposed to be visible to his
> package.  If GNAT is accepting this, this means that some stuff that
> should be invisible is visible, and that's a bug.
> 
>                               -- Adam

Recalling an earlier conversation : this (visibility of private parts) 
strikes me as a candidate for submission to the ACATS suite; though it 
would surprise me if ACATS doesn't cover this in some depth already.

One question is : can the same error be reproduced with a less specific 
test case (type A is interface ... ), or has Gnat special-cased 
controlled types such that the error only appears with Ada.Finalization 
and procedures named Adjust etc?

The latter I can understand to some extent; but if the former ... what 
went wrong?

- Brian

Re: How many Ada compiler bugs are here?

[Randy Brukardt]

"Brian Drummond" <brian@shapes.demon.co.uk> wrote in message 
news:jes008$q0f$1@dont-email.me...
> On Fri, 13 Jan 2012 15:30:37 -0800, Adam Beneschan wrote:
...
> Recalling an earlier conversation : this (visibility of private parts)
> strikes me as a candidate for submission to the ACATS suite; though it
> would surprise me if ACATS doesn't cover this in some depth already.

Keep in mind that the ACATS doesn't try to guess the errors that a compiler 
implementer might make, as that is nearly an infinite set. Rather, it tries 
to have at least one test of Legality Rule in the standard; combinations of 
multiple rules (as in this case) are not a priority.

The Ada 83 ACVC tried much hard to make such guesses. But the effect was a 
lot of rather pointless tests that tried to guess what syntax a compiler 
writer might want to allow beyond that in the Standard. All of those tests 
were removed from the Ada 95 ACVC (which became the ACATS), as their only 
value was to stress compiler syntax error correction/handling (which is not 
an intended purpose of the ACATS!). Indeed, there is rule against including 
syntax error tests in the ACATS (with an exception made for "syntax" that 
most likely will be enforced post-syntax; one example is the rules about 
others limbs in case statements).

Which is a long way to say that I don't think there is any attempt to 
declare Adjust for a limited type, and if there is, it would be an Ada 95 
C-Test in which case there would be no "overriding" involved.

                                             Randy.

Re: How many Ada compiler bugs are here?

[Adam Beneschan]

On Jan 18, 5:47 pm, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
> "Brian Drummond" <br...@shapes.demon.co.uk> wrote in message
>
> news:jes008$q0f$1@dont-email.me...
>
> > On Fri, 13 Jan 2012 15:30:37 -0800, Adam Beneschan wrote:
> ...
> > Recalling an earlier conversation : this (visibility of private parts)
> > strikes me as a candidate for submission to the ACATS suite; though it
> > would surprise me if ACATS doesn't cover this in some depth already.
>
> Keep in mind that the ACATS doesn't try to guess the errors that a compiler
> implementer might make, as that is nearly an infinite set.

And some days it seems like I've made all of them.

Of course, I could really quibble about what "nearly infinite" means.
However big the set of possible errors is, I'm sure it's still
billions, maybe even trillions, short of infinity.  :)

                            -- Adam

Re: How many Ada compiler bugs are here?

[Randy Brukardt]

"Adam Beneschan" <adam@irvine.com> wrote in message 
news:75df28b7-e784-41a1-9c40-9520fb6f1c0d@v14g2000yqh.googlegroups.com...
>On Jan 18, 5:47 pm, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
>> "Brian Drummond" <br...@shapes.demon.co.uk> wrote in message
>> ...
>> > Recalling an earlier conversation : this (visibility of private parts)
>> > strikes me as a candidate for submission to the ACATS suite; though it
>> > would surprise me if ACATS doesn't cover this in some depth already.
>>
>> Keep in mind that the ACATS doesn't try to guess the errors that a 
>> compiler
>> implementer might make, as that is nearly an infinite set.
>
>And some days it seems like I've made all of them.

Been there, done that.

>Of course, I could really quibble about what "nearly infinite" means.
>However big the set of possible errors is, I'm sure it's still
>billions, maybe even trillions, short of infinity.  :)

True enough. For the purposes of a test suite, it might as well be infinite, 
even if the actual number is "finite but very large". An ACATS with 10 
billion tests would be hard to process...

Aside: I note that security testers are putting a lot of work into "fuzzing" 
tools. One could imagine building such a tool for Ada syntax; it could 
create thousands of programs each containing a single error in many 
different ways. But I'd be somewhat dubious about the value of such a tool, 
as it would a take a lot of effort to create and probably wouldn't find a 
lot of errors. (Mainly because many compilers use a table-driven parser 
[Janus/Ada does], so the only way to get parsing errors is to have mistakes 
in the original grammar definition. Those happen, but they're relatively 
obvious and easy to fix when found. Even in compilers with hand-written 
parsers, [like GNAT], errors are fairly unlikely and obvious.)

A fuzzing tool would be a lot more useful if it could generate Legality 
errors automatically, but I don't think that is possible beyond a very 
limited subset.

                                            Randy.




                            -- Adam 

Re: How many Ada compiler bugs are here?

[Maciej Sobczak]

On Jan 13, 1:21 am, "Randy Brukardt" <ra...@rrsoftware.com> wrote:

> > 3. Logically, Tmp is never created, because Make_T raises an
> > exception. Somehow some object is finalized. Apparently it is Tmp,
> > which should not exist.
> > 4. Somehow Tmp.initialized = True, even though its default value is
> > defined to be False.
>
> I'm not sure if these are actually bugs or not; the fact that Adjust is
> being called for a limited object means to me that nothing that happens
> afterwards makes any sense

Adjust is not called, but I have defined it to check if that's the
case.
Still, Adjust is not the biggest issue here, neither is the
requirement for the return statement.
The biggest issue is that the compiler fails to initialize some object
(even ignoring the statically provided field initializers) and yet
considers it to be worthy finalization - and the Finalize operation
has absolutely no line of defense against this. This is a *very*
serious problem.
I have found it, because my program was crashing.
And since this relates to the very fundamentals of the object model,
this bug is not to be ignored. I can live with the rest, but this one
is really serious.

The workaround is this:

   type T is limited private;

(note the lack of indefinite constraint - that is, we allow default
objects)
and then:

   procedure Init (Val : in out T; whateverelsehere);

This works, but introduces the notion of uninitialized (default)
object. The original version was stronger as it only allowed full
proper objects.

--
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com

Re: How many Ada compiler bugs are here?

[Brian Drummond]

On Sat, 14 Jan 2012 02:20:19 -0800, Maciej Sobczak wrote:

> The biggest issue is that the compiler fails
> to initialize some object (even ignoring the statically provided field
> initializers) and yet considers it to be worthy finalization - and the
> Finalize operation has absolutely no line of defense against this. This
> is a *very* serious problem.

I would agree with that!

However the following may be of interest:

brian@linnet:~/projects/ada/bugs> gnat --version
GNAT 4.6.2 20111212 [gcc-4_6-branch revision 182222]
Copyright 1996-2010, Free Software Foundation, Inc.
...
brian@linnet:~/projects/ada/bugs> gnatmake test
...
gnatlink: warning: executable name "test" may conflict with shell command
brian@linnet:~/projects/ada/bugs> ./test
exception handled
brian@linnet:~/projects/ada/bugs> 

Not a whisper from finalization.
However it still doesn't flag Adjust as illegal.

- Brian

Re: How many Ada compiler bugs are here?

[Adam Beneschan]

On Jan 14, 2:20 am, Maciej Sobczak <see.my.homep...@gmail.com> wrote:
> On Jan 13, 1:21 am, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
>
> > > 3. Logically, Tmp is never created, because Make_T raises an
> > > exception. Somehow some object is finalized. Apparently it is Tmp,
> > > which should not exist.
> > > 4. Somehow Tmp.initialized = True, even though its default value is
> > > defined to be False.
>
> > I'm not sure if these are actually bugs or not; the fact that Adjust is
> > being called for a limited object means to me that nothing that happens
> > afterwards makes any sense
>
> Adjust is not called, but I have defined it to check if that's the
> case.
> Still, Adjust is not the biggest issue here, neither is the
> requirement for the return statement.
> The biggest issue is that the compiler fails to initialize some object
> (even ignoring the statically provided field initializers) and yet
> considers it to be worthy finalization - and the Finalize operation
> has absolutely no line of defense against this. This is a *very*
> serious problem.
> I have found it, because my program was crashing.
> And since this relates to the very fundamentals of the object model,
> this bug is not to be ignored. I can live with the rest, but this one
> is really serious.

I think what Randy was getting at--and I concur with this--is that if
you can create a *legal* program that has the bug you're concerned
about (i.e. one that does not try to override a non-existent Adjust),
then it's a serious problem and you should definitely report it.  But
if you can't, I wouldn't worry about it.  You're probably thinking
that you've run across a serious problem in the object model that's
**independent** of the Adjust visibility issue.  But to me, there's a
good chance that this problem is intertwined with the Adjust problem,
not independent of it.  That's because as a compiler developer myself,
I'm aware of the kind of special things compilers need to do to handle
Controlled and Limited_Controlled.  If something goes wrong with that,
I can easily imagine how this could lead to all sorts of other things
going wrong.

                                -- Adam

Re: How many Ada compiler bugs are here?

[Brian Drummond]

On Mon, 16 Jan 2012 08:35:55 -0800, Adam Beneschan wrote:

> On Jan 14, 2:20 am, Maciej Sobczak <see.my.homep...@gmail.com> wrote:
>> Adjust is not called, but I have defined it to check if that's the
>> case.

> I think what Randy was getting at--and I concur with this--is that if
> you can create a *legal* program that has the bug you're concerned about
> (i.e. one that does not try to override a non-existent Adjust), then
> it's a serious problem and you should definitely report it.  But if you
> can't, I wouldn't worry about it.  You're probably thinking that you've
> run across a serious problem in the object model that's **independent**
> of the Adjust visibility issue.  But to me, there's a good chance that
> this problem is intertwined with the Adjust problem, not independent of
> it. 

That was my concern too. However my limited attempts to create a testcase 
for visibility errors independent of controlled types, failed to do so. 
I believe you are correct that it arises out of some special case 
handling, and nothing deeper. 


- Brian