Bus error

Bus error

[Maciej Sobczak]

I have found a problem with my compiler:

-- a.ads
with Ada.Finalization;
package A is

   type T is tagged limited private;

   function Make return T;

private

   type T is new Ada.Finalization.Limited_Controlled with
      record
         X : Integer;
      end record;

   overriding procedure Finalize(V : in out T);

end A;

-- a.adb
with Ada.Text_IO;
package body A is

   function Make return T is
   begin
      return (Ada.Finalization.Limited_Controlled with 7);
   end Make;

   procedure Finalize(V : in out T) is
   begin
      Ada.Text_IO.Put("Finalizing T");
   end;

end A;

-- hello.adb
with A;
procedure Hello is
   Y : A.T := A.Make;
begin
   null;
end Hello;

$ gnatmake hello
gcc -c hello.adb
gcc -c a.adb
gnatbind -x hello.ali
gnatlink hello.ali
$ ./hello
Bus error
$

GNAT version: 4.3.0 20070527 (experimental)

BTW - is the code correct at all? I'm worried about A.Make in
particular.

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

Re: Bus error

[Georg Bauhaus]

On Wed, 2007-06-27 at 07:23 -0700, Maciej Sobczak wrote:
> I have found a problem with my compiler:
> 
> -- a.ads
> with Ada.Finalization;
> package A is
> 
>    type T is tagged limited private;
> 
>    function Make return T;

As it happens, the masters--who are probably all in Geneva now--
have been discussing a related issue on Ada_Comment.
The archives might have some hints.

> $ gnatmake hello
> gcc -c hello.adb
> gcc -c a.adb
> gnatbind -x hello.ali
> gnatlink hello.ali
> $ ./hello
> Bus error
> $

(Do you get a different effect when you try compiling
with -O -g -a -gnata -gnato?)

> GNAT version: 4.3.0 20070527 (experimental)
> 
> BTW - is the code correct at all? I'm worried about A.Make in
> particular.

Procedure Make should be fine as the object returned is to be
built in place. (As per Bob Duff's "gems" on limited aggregates
and other sources.)

Re: Bus error

[Maciej Sobczak]

On 27 Cze, 17:45, Georg Bauhaus <rm.tsoh+bauh...@maps.futureapps.de>
wrote:

> > -- a.ads
> > with Ada.Finalization;
> > package A is
>
> >    type T is tagged limited private;
>
> >    function Make return T;
>
> As it happens, the masters--who are probably all in Geneva now--
> have been discussing a related issue on Ada_Comment.
> The archives might have some hints.

Google group search does not find anything.
And yes, Geneva is a good place for discussing Ada now, although it's
a bit rainy this week. ;-)

> (Do you get a different effect when you try compiling
> with -O -g -a -gnata -gnato?)

Yes, there is a difference - it took me longer to type the commands
before I got bus error...

> Procedure Make should be fine as the object returned is to be
> built in place. (As per Bob Duff's "gems" on limited aggregates
> and other sources.)

Except that those gems don't tell much about extension aggregates and
even less about limited controlled.

BTW - is it necessary to reveal in the public view that the type is
tagged? It is tagged only so that it can be controlled and since this
is implementation detail,
it should be private together with the extension.
I cannot check it, because this time I get the explicit "GNAT BUG
DETECTED".

Ideally, the public view should look like this:

type T (<>) is limited private;

With the private view unchanged. Is it possible? (assuming good
compiler)

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

Re: Bus error

[Robert A Duff]

Maciej Sobczak <see.my.homepage@gmail.com> writes:

> On 27 Cze, 17:45, Georg Bauhaus <rm.tsoh+bauh...@maps.futureapps.de>
> wrote:
>> Procedure Make should be fine as the object returned is to be
>> built in place. (As per Bob Duff's "gems" on limited aggregates
>> and other sources.)

Thanks for mentioning the "gems", Georg.

> Except that those gems don't tell much about extension aggregates and
> even less about limited controlled.

There are a few more gems on this subject in the pipeline -- stay tuned.

http://www.adacore.com/category/developers-center/gems

> BTW - is it necessary to reveal in the public view that the type is
> tagged?

No.  You can have an untagged private type whose full type is tagged.
That means that clients cannot extend the type, but child packages can.

>... It is tagged only so that it can be controlled and since this
> is implementation detail,
> it should be private together with the extension.

Right.

> I cannot check it, because this time I get the explicit "GNAT BUG
> DETECTED".

...which requests that you send a bug report.  If you're not a supported
customer of AdaCore, and you send a bug report, it will eventually get
fixed (but it's lower priority than paying customers).

> Ideally, the public view should look like this:
>
> type T (<>) is limited private;
>
> With the private view unchanged. Is it possible? (assuming good
> compiler)

Yes, that's possible.  Assuming a bug-free compiler, of course. ;-).

As to your original question, about an extension aggregate: I don't see
anything wrong with your code, and I do recall fixing a bug in that area
(extension aggregate of limited type with controlled parts returned from
build-in-place function) a month or so ago.  The bug fix will eventually
find its way into the public version of GNAT.

- Bob

Re: Bus error

[Maciej Sobczak]

On 28 Cze, 03:58, Robert A Duff <bobd...@shell01.TheWorld.com> wrote:

> > BTW - is it necessary to reveal in the public view that the type is
> > tagged?
>
> No.  You can have an untagged private type whose full type is tagged.

You mean - untagged *public*, I suppose?

> > I cannot check it, because this time I get the explicit "GNAT BUG
> > DETECTED".
>
> ...which requests that you send a bug report.

I conclude that AdaCore guys read comp.lang.ada as well. :-)

> As to your original question, about an extension aggregate: I don't see
> anything wrong with your code, and I do recall fixing a bug in that area
> (extension aggregate of limited type with controlled parts returned from
> build-in-place function) a month or so ago.  The bug fix will eventually
> find its way into the public version of GNAT.

That's a good news, really. I consider this feature (limited
controlled with unknown discriminant) to be fundamental for correct
handling of external resources and other "interesting" types. It is
really a high time for this feature to get a wider adoption.

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

Re: Bus error

[Robert A Duff]

Maciej Sobczak <see.my.homepage@gmail.com> writes:

> On 28 Cze, 03:58, Robert A Duff <bobd...@shell01.TheWorld.com> wrote:
>
>> > BTW - is it necessary to reveal in the public view that the type is
>> > tagged?
>>
>> No.  You can have an untagged private type whose full type is tagged.
>
> You mean - untagged *public*, I suppose?

Yeah, the terminology is confusing.  I mean:

    package P is
        type T is limited private;
    private
        type T is tagged limited ...;
    end P;

or:

    with Ada.Finalization; use Ada;
    package P is
        type T is limited private;
    private
        type T is new Finalization.Limited_Controlled with ...;
    end P;

Both of the above are legal.

>> > I cannot check it, because this time I get the explicit "GNAT BUG
>> > DETECTED".
>>
>> ...which requests that you send a bug report.
>
> I conclude that AdaCore guys read comp.lang.ada as well. :-)

Not really.  ;-)

I read it once in a while, but often not for months at a time.
Most AdaCore folks do not read comp.lang.ada at all.

And AdaCore certainly does not go looking for GNAT bugs on
comp.lang.ada.  If you want a bug fixed, you have to send
an official bug report.  And if you want it fixed fast,
or want AdaCore to answer your questions, you have to spend
money.

>> As to your original question, about an extension aggregate: I don't see
>> anything wrong with your code, and I do recall fixing a bug in that area
>> (extension aggregate of limited type with controlled parts returned from
>> build-in-place function) a month or so ago.  The bug fix will eventually
>> find its way into the public version of GNAT.
>
> That's a good news, really. I consider this feature (limited
> controlled with unknown discriminant) to be fundamental for correct
> handling of external resources and other "interesting" types. It is
> really a high time for this feature to get a wider adoption.

Right, but it's the Ada 2005 build-in-place function return stuff that
makes these really useful.  The bug we're talking about (assuming it
really is the same bug that I fixed, which I can't promise) was a
nasty interaction between build-in-place functions and controlled
types.

- Bob

Re: Bus error

[Maciej Sobczak]

On 28 Cze, 23:19, Robert A Duff <bobd...@shell01.TheWorld.com> wrote:

> >> No.  You can have an untagged private type whose full type is tagged.
>
> > You mean - untagged *public*, I suppose?
>
> Yeah, the terminology is confusing.

Yes, I meant "untagged public view". If any such thing exists. :-)

> I mean:
>
>     package P is
>         type T is limited private;
>     private
>         type T is tagged limited ...;
>     end P;
>
> or:
>
>     with Ada.Finalization; use Ada;
>     package P is
>         type T is limited private;
>     private
>         type T is new Finalization.Limited_Controlled with ...;
>     end P;

Yes, or even stricter:

    with Ada.Finalization; use Ada;
    package P is
        type T (<>) is limited private;
    private
        type T is new Finalization.Limited_Controlled with ...;
    end P;

which prevents uninitialized objects.

> Most AdaCore folks do not read comp.lang.ada at all.

Interesting.
Do they have so many official user complaints to read that they don't
have any time left? :-)

Hey, I can afford this joke, if they don't read it, right?

> And AdaCore certainly does not go looking for GNAT bugs on
> comp.lang.ada.  If you want a bug fixed, you have to send
> an official bug report.  And if you want it fixed fast,
> or want AdaCore to answer your questions, you have to spend
> money.

This is short-sighted. What if I'm not *yet* an Ada user, but just
contemplate this possibility and take into account *everything*,
including the consistency of Ada community?
By neglecting c.l.a. they're risking to lose a potential customer(s).

> > I consider this feature (limited
> > controlled with unknown discriminant) to be fundamental for correct
> > handling of external resources and other "interesting" types. It is
> > really a high time for this feature to get a wider adoption.
>
> Right, but it's the Ada 2005 build-in-place function return stuff that
> makes these really useful.

Yes. Interestingly, it works fine with my compiler. I just consider
the aggregate to be more concise in simpler cases.

>  The bug we're talking about (assuming it
> really is the same bug that I fixed, which I can't promise) was a
> nasty interaction between build-in-place functions and controlled
> types.

Controlled types are messy.

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

Re: Bus error

[Georg Bauhaus]

Maciej Sobczak wrote:
>
> Yes, or even stricter:
> 
>     with Ada.Finalization; use Ada;
>     package P is
>         type T (<>) is limited private;
>     private
>         type T is new Finalization.Limited_Controlled with ...;
>     end P;
> 
> which prevents uninitialized objects.

Uhm, it prevents uninitialized objects that cannot otherwise
have default initialisation (e.g. from function calls whose
results are assigned to components), or initialisation via Initialize.
Such as records that need their components initialised with
values known only at run time *and* defined at library level etc.

In a less flat architecture (which dismisses the possibilites of
nested block structure :), consider a plain limited type T in some
suitably nested block:


procedure Operate_System_95 is


    type External_State is new Natural;

    outside: External_State;
    

    
    package P is

        type T is limited private;

    private
        
        type Void is null record;
    
        function Constructor(Object: access T) return Void;
        
        type T is limited record
            hook: Void := Constructor(T'access);
            count: Natural;
        end record;

    end P;

    package body P is
    
        function Constructor(Object: access T) return Void is
        begin
            Object.count := Natural(outside);
            return (null record);
        end Constructor;
        
    end P;

    V: P.T;  --  initialisation via Constructor is guaranteed

begin
    null;
end Operate_System_95;

Re: Bus error

[Adam Beneschan]

On Jun 29, 2:42 am, Georg Bauhaus <bauh...@futureapps.de> wrote:
> Maciej Sobczak wrote:
>
> > Yes, or even stricter:
>
> >     with Ada.Finalization; use Ada;
> >     package P is
> >         type T (<>) is limited private;
> >     private
> >         type T is new Finalization.Limited_Controlled with ...;
> >     end P;
>
> > which prevents uninitialized objects.
>
> Uhm, it prevents uninitialized objects that cannot otherwise
> have default initialisation (e.g. from function calls whose
> results are assigned to components), or initialisation via Initialize.
> Such as records that need their components initialised with
> values known only at run time *and* defined at library level etc.

I'm not sure what you mean here... For packages that can only see the
partial view of T, T is an indefinite type, and you cannot declare a
variable of type T without an initialization expression (3.3.1(5)).  I
think that's what Maciej was referring to.  (Yes, a private child
package of P could declare a variable of type T without an
initializer, but I don't think he was referring to those.)

                    -- Adam

Re: Bus error

[Georg Bauhaus]

Adam Beneschan wrote:
> On Jun 29, 2:42 am, Georg Bauhaus <bauh...@futureapps.de> wrote:
>> Maciej Sobczak wrote:
>>
>>> Yes, or even stricter:
>>>     with Ada.Finalization; use Ada;
>>>     package P is
>>>         type T (<>) is limited private;
>>>     private
>>>         type T is new Finalization.Limited_Controlled with ...;
>>>     end P;
>>> which prevents uninitialized objects.
>> Uhm, it prevents uninitialized objects that cannot otherwise
>> have default initialisation (e.g. from function calls whose
>> results are assigned to components), or initialisation via Initialize.
>> Such as records that need their components initialised with
>> values known only at run time *and* defined at library level etc.
> 
> I'm not sure what you mean here... For packages that can only see the
> partial view of T, T is an indefinite type, and you cannot declare a
> variable of type T without an initialization expression (3.3.1(5)).  I
> think that's what Maciej was referring to.  (Yes, a private child
> package of P could declare a variable of type T without an
> initializer, but I don't think he was referring to those.)

I was only thinking of guaranteed initialisation of an object of a
limited type T that is declared just anywhere even when it is not
explicitly initialised. The idea being that T then doesn't necessarily
need (<>) in its public view because T's default initialization
might take care of all components via

  type T is limited ...
     Xyz_Part : D := Init_All_Copmonents(T'access, ...);

This, I thought, is made possible through the venerable
mechanisms "limited" and visibility control. That is, just like we can
make a no-argument constructor of a Java class call methods on "this",
we can make variables of a limited type T call functions on "T'access"
(by not using an Ada 2005 constructor function in this case).

And I'm glad that we can now have aggregates of limited types for
building connected (partially) immutable data structures in source.
And all kinds of constants of limited types.

Re: Bus error

[Robert A Duff]

Maciej Sobczak <see.my.homepage@gmail.com> writes:

> On 28 Cze, 23:19, Robert A Duff <bobd...@shell01.TheWorld.com> wrote:
>
>> >> No.  You can have an untagged private type whose full type is tagged.
>>
>> > You mean - untagged *public*, I suppose?
>>
>> Yeah, the terminology is confusing.
>
> Yes, I meant "untagged public view". If any such thing exists. :-)

The RM term is "partial view".

>> I mean:
>>
>>     package P is
>>         type T is limited private;
>>     private
>>         type T is tagged limited ...;
>>     end P;
>>
>> or:
>>
>>     with Ada.Finalization; use Ada;
>>     package P is
>>         type T is limited private;
>>     private
>>         type T is new Finalization.Limited_Controlled with ...;
>>     end P;
>
> Yes, or even stricter:
>
>     with Ada.Finalization; use Ada;
>     package P is
>         type T (<>) is limited private;
>     private
>         type T is new Finalization.Limited_Controlled with ...;
>     end P;
>
> which prevents uninitialized objects.

As written, it prevents clients from creating ANY objects of
type T.  Clients cannot create uninitialized objects ("X:T;",
or "new T;") because of the (<>).  And clients cannot create
initialized objects, because no functions are exported.

In a real example, T might be Set, and there would be some
functions like:

    function Empty_Set return Set;
    function Intersection (...) return Set;

The (<>) means clients can't create objects of type Set without
initializing them with some function under control of the Sets
package.

>> Most AdaCore folks do not read comp.lang.ada at all.
>
> Interesting.
> Do they have so many official user complaints to read that they don't
> have any time left? :-)
>
> Hey, I can afford this joke, if they don't read it, right?

;-)

- Bob

Re: Bus error

[Dmitry A. Kazakov]

On Thu, 28 Jun 2007 13:06:49 -0700, Maciej Sobczak wrote:

> That's a good news, really. I consider this feature (limited
> controlled with unknown discriminant) to be fundamental for correct
> handling of external resources and other "interesting" types. It is
> really a high time for this feature to get a wider adoption.

Hmm, that depends on "interest." Maybe I am wrong, but I think that one
objection against Ada 2005 design is that now it is impossible to have
types which objects were strictly temporal, i.e. to prevent creation of
variables. Consider this:

 [  type T (<>) is limited private; ]

   X : T := Factory; -- Was illegal in Ada 95

   Foo (Factory); -- That's OK

(Ada 95 design was of course flawed too, because you could not do, say:

   Foo (Factory & Factory); -- Couldn't do this in Ada 95)

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

AW: Bus error

[Grein, Christoph (Fa. ESG)]

> ... one objection against Ada 2005 design is that now it is impossible
to > have types which objects were strictly temporal, i.e. to prevent
creation > of variables. Consider this:
>
> [  type T (<>) is limited private; ]
>
>   X : T := Factory; -- Was illegal in Ada 95
>
>   Foo (Factory); -- That's OK

Was this feature, which is now lost, often used and very important? Then
we should consider making it again available in the next Ada version. So
put a request to Ada Comment.


Eurocopter Deutschland GmbH
Sitz der Gesellschaft/Registered Office: Donauwoerth
Registergericht/Registration Court: Amtsgericht Augsburg HRB 16508
Vorsitzender des Aufsichtsrates/Chairman of the Supervisory Board: Dr. Lutz Bertling
Geschaeftsfuehrung/Board of Management:
Dr. Wolfgang Schoder, Vorsitzender/CEO; Friedrich-Wilhelm Hormel; Ralf Barnscheidt

CONFIDENTIALITY NOTICE 

This communication and the information it contains is intended for the addressee(s) named above and for no other persons or organizations. It is confidential and may be legally privileged and protected by law. The unauthorized use, copying or disclosure of this communication or any part of it is prohibited and may be unlawful. 
If you have received this communication in error, kindly notify us by return e-mail and discard and/or delete the communication. Thank you very much. 
It is possible for e-mails to be intercepted or affected by viruses. Whilst we maintain virus checks on our e-mails, we accept no liability for viruses or other material which might be introduced with this message. 

Re: Bus error

[Dmitry A. Kazakov]

On Fri, 29 Jun 2007 11:23:08 +0200, Grein, Christoph (Fa. ESG) wrote:

> Was this feature, which is now lost, often used and very important?

No so oft. One example I know is immutable lists of strings [actually any
unconstrained objects]. We don't have aggregates or tuples of, so let's
emulate them using a limited types:

   type List (<>) is limited private;
   function "/" (L, R : String) return List;
   function "/" (L : List, R : String) return List;

   procedure Foo (X : List);

We could call Foo as

   Foo ("A" / "B" / "C" / "D");

Let we wanted to prevent the second "/" from copying lists. In order to do
so, we would implement List as a controlled record containing a pointer to
a reference-counted implementation of the list. So "/" would actually
modify target of left argument in hope that it would vanish anyway. It
will, if there were impossible to create a variable of List.

   X : List := "A" / "B";
   Y : List := X / "C";   -- Surprise!

> Then
> we should consider making it again available in the next Ada version.

Have you an idea of how it could be done? It looks difficult to me.

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

Re: Bus error

[Anh Vo]

On Jun 27, 7:23 am, Maciej Sobczak <see.my.homep...@gmail.com> wrote:
> I have found a problem with my compiler:
>
> -- a.ads
> with Ada.Finalization;
> package A is
>
>    type T is tagged limited private;
>
>    function Make return T;
>
> private
>
>    type T is new Ada.Finalization.Limited_Controlled with
>       record
>          X : Integer;
>       end record;
>
>    overriding procedure Finalize(V : in out T);
>
> end A;
>
> -- a.adb
> with Ada.Text_IO;
> package body A is
>
>    function Make return T is
>    begin
>       return (Ada.Finalization.Limited_Controlled with 7);
>    end Make;
>
>    procedure Finalize(V : in out T) is
>    begin
>       Ada.Text_IO.Put("Finalizing T");
>    end;
>
> end A;
>
> -- hello.adb
> with A;
> procedure Hello is
>    Y : A.T := A.Make;
> begin
>    null;
> end Hello;
>
> $ gnatmake hello
> gcc -c hello.adb
> gcc -c a.adb
> gnatbind -x hello.ali
> gnatlink hello.ali
> $ ./hello
> Bus error
> $
>
> GNAT version: 4.3.0 20070527 (experimental)
>
> BTW - is the code correct at all? I'm worried about A.Make in
> particular.
>
> --
> Maciej Sobczakhttp://www.msobczak.com/

With the lattest snapshot gcc-4.3-20070622 a bug box resulted as shown
below

bash-2.05b$ gnatmake hello.adb
gcc -c hello.adb
gcc -c a.adb
+===========================GNAT BUG
DETECTED==============================+
| 4.3.0 20070615 (experimental) (i686-pc-linux-gnu) Assert_Failure
namet.adb:687|
| Error detected at a.adb:
10:7                                             |
| Please submit a bug report; see http://gcc.gnu.org/bugs.html.
|
| Use a subject line meaningful to you and us to track the
bug.            |
| Include the entire contents of this bug box in the
report.               |
| Include the exact gcc or gnatmake command that you
entered.              |
| Also include sources listed below in gnatchop
format                     |
| (concatenated together with no headers between
files).                   |
+==========================================================================
+

Please include these source files with error report
Note that list may not be accurate in some cases,
so please double check that the problem can still
be reproduced with the set of files listed.

a.adb
a.ads

compilation abandoned
gnatmake: "a.adb" compilation error

When compiled with GNAT-GPL-2007, an error is detected

gcc -c hello.adb
gcc -c a.adb
a.adb:10:07: "" is undefined
a.adb:10:07: actual for "From" must be a variable
gnatmake: "a.adb" compilation error

However, if the return statement is fully qualified as below, it works
fine on all versions

$$$       return T'(Ada.Finalization.Limited_Controlled with 7);

AV

Re: Bus error

[Maciej Sobczak]

On 27 Cze, 22:02, Anh Vo <anhvofrc...@gmail.com> wrote:

> However, if the return statement is fully qualified as below, it works
> fine on all versions
>
> $$$       return T'(Ada.Finalization.Limited_Controlled with 7);

I still get bus error with this.
Why should that make any difference, anyway (other than guessing
around the compiler bug)? Qualification should not be necessary in
this context, because the expected type for the aggregate is known
from the function return type. There is no ambiguity here that would
need to be resolved with the qualification.

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

Re: Bus error

[Robert A Duff]

Maciej Sobczak <see.my.homepage@gmail.com> writes:

> On 27 Cze, 22:02, Anh Vo <anhvofrc...@gmail.com> wrote:
>
>> However, if the return statement is fully qualified as below, it works
>> fine on all versions
>>
>> $$$       return T'(Ada.Finalization.Limited_Controlled with 7);
>
> I still get bus error with this.
> Why should that make any difference, anyway (other than guessing
> around the compiler bug)? Qualification should not be necessary in
> this context, because the expected type for the aggregate is known
> from the function return type. There is no ambiguity here that would
> need to be resolved with the qualification.

You are correct -- the return T'(...) version should behave the same as
the return (...) version.  If it doesn't, that's probably a bug in the
compiler.

Either way, I don't see any good reason for a bus error here.

- Bob

Re: AW: Bus error

[Duncan Sands]

> > ... one objection against Ada 2005 design is that now it is impossible
> to > have types which objects were strictly temporal, i.e. to prevent
> creation > of variables. Consider this:
> >
> > [  type T (<>) is limited private; ]
> >
> >   X : T := Factory; -- Was illegal in Ada 95
> >
> >   Foo (Factory); -- That's OK

in Ada 95 you could do

	X : T renames Factory;

Ciao,

Duncan.