comp.lang.ada
 help / color / mirror / Atom feed
From: Stephen Leake <stephen_leake@stephe-leake.org>
Subject: Re: Issue with GNAT GPL 2009 and GtkAda
Date: Tue, 30 Jun 2009 07:11:27 -0400
Date: 2009-06-30T07:11:27-04:00	[thread overview]
Message-ID: <uvdmem0ww.fsf@stephe-leake.org> (raw)
In-Reply-To: wcc1vp5sj4g.fsf@shell01.TheWorld.com

Robert A Duff <bobduff@shell01.TheWorld.com> writes:

> Stephen Leake <stephen_leake@stephe-leake.org> writes:
>
>> "Randy Brukardt" <randy@rrsoftware.com> writes:
>>
>>>>Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message 
>>>>news:4a44ae4e$0$6295$4f793bc4@news.tdc.fi...
>>> I think he means that the accessibility level of a parameter is that of a 
>>> local object, ...
>
> Yes, the accessibility level of a formal parameter is like a local
> nested inside the procedure.  This is true for tagged and untagged.
>
>>...as it *might* have been passed by copy. 
>
> Not for tagged -- those are always passed by reference.
>
>> Well, I had forgotten that tagged types are by reference, so I meant
>> it might _actually_ be passed by copy. But apparently the compiler
>> isn't taking advantage of the fact that tagged types are by reference,
>> and is taking the more conservative view that it might be passed by copy.
>
> The compiler is just doing what the language rules require.
>
> Note that "must be passed by reference" does not imply "we could allow
> 'Access".  Consider:
>
>     type T_Ref is access all T;
>     Global : T_Ref;
>
>     procedure P (X : in out T) is -- Suppose T is tagged.
>     begin
>         Global := X'Access; -- Illegal!
>     end P;
>
>     procedure Q (...) is
>         Local : aliased T;
>     begin
>         P (Local);
>     end Q;
>
> After calling Q, Global is a dangling pointer.  The language design rule
> is:  If you do anything that _might_ create a dangling pointer, you
> have to use 'Unchecked_Access (and take care).

But if X was actually a global object, 'Access would be ok; I thought
the run-time accessibility checks would handle that case for tagged
types.

But apparently accessibility information is only passed with access
parameters (either 'access', or 'in [out]' of an access type).

> ..
> In my view, this makes the language _more_ complicated, and if
> "aliased" is dangerous, surely implicit aliased is even more so.

I agree with that!

>>> The only way that we could have done better would be to pass an 
>>> accessibility level with every tagged parameter. That seems like way too 
>>> much overhead.
>>
>> I see. So the rules are more conservative than they could be, leading
>> to programmer surprises like this one.
>
> No, I don't think they're overly conservative -- see my dangling pointer
> example above.  Well, of course compile-time checks are always
> conservative (see halting problem!).  The only way to be less
> conservative would be to do more checks at run time, which
> is heading in the wrong direction.

This is my key mis-understanding. If 'in out' parameters of tagged types
carried accessibility information that could be checked at runtime,
the above example would be ok.

I'm not clear why you say that is the "wrong direction".

>> Except that I'm not clear how accessiblity information is passed now.
>> Since it's a runtime check, it seems the accessiblity level must be
>> stored with the access object somehow; what is the extra overhead you
>> are talking about?
>
> In most compilers, the accessibility level is represented as an integer,
> and this integer is passed as an extra implicit parameter whenever
> you have an access parameter.  So your Foreach procedure really
> has three parameters: B, I, and the accessibility level of B.all.

Right. So I'm proposing that same extra parameter be passed for each
'in out' parameter of a tagged type.

I can see how that is more distributed overhead, on the off chance
that somebody might use 'Access.

Personally, I like the rule:
     
    If the body needs an access value, pass in an access value.

which works fine with the current Ada rules.

But it makes 'access' visible all over the place, which some people
don't like.

-- 
-- Stephe



  reply	other threads:[~2009-06-30 11:11 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-23 21:52 Issue with GNAT GPL 2009 and GtkAda Damien Carbonne
2009-06-24  7:40 ` Dmitry A. Kazakov
2009-06-24 10:15 ` Stephen Leake
2009-06-25  9:06   ` Stephen Leake
2009-06-25  9:39     ` Dmitry A. Kazakov
2009-06-25 19:02       ` Damien Carbonne
2009-06-26  9:31         ` Stephen Leake
2009-06-26 11:18           ` Niklas Holsti
2009-06-26 16:29             ` Damien Carbonne
2009-06-26 17:28               ` Dmitry A. Kazakov
2009-06-26 19:27                 ` Damien Carbonne
2009-06-26 19:50                   ` Dmitry A. Kazakov
2009-06-26 21:51             ` Randy Brukardt
2009-06-27 11:11               ` Stephen Leake
2009-06-27 17:04                 ` Robert A Duff
2009-06-30 11:11                   ` Stephen Leake [this message]
2009-06-30 18:10                     ` Robert A Duff
2009-06-29 22:11                 ` Randy Brukardt
2009-06-30 11:13                   ` Stephen Leake
2009-06-30 15:26                     ` Adam Beneschan
2009-06-30 15:59               ` Adam Beneschan
2009-06-30 23:11                 ` Randy Brukardt
2009-06-27  9:56             ` Stephen Leake
2009-06-26 21:03           ` Damien Carbonne
2009-06-27 11:21             ` Stephen Leake
2009-06-27 12:25               ` Damien Carbonne
2009-06-27 12:35                 ` Damien Carbonne
2009-06-29 22:15                   ` Randy Brukardt
2009-07-01 19:22                     ` Damien Carbonne
2009-06-30  0:48             ` Adam Beneschan
2009-06-30 11:18               ` Stephen Leake
2009-06-25 20:49       ` Randy Brukardt
2009-06-26  7:20         ` Dmitry A. Kazakov
2009-06-26  8:17           ` Georg Bauhaus
2009-06-26  8:52             ` Dmitry A. Kazakov
2009-06-26 21:38               ` Randy Brukardt
2009-06-27  7:47                 ` Dmitry A. Kazakov
2009-06-29 21:59                   ` Randy Brukardt
2009-06-30  8:31                     ` Dmitry A. Kazakov
2009-06-26 21:31           ` Randy Brukardt
2009-06-27  7:53             ` Dmitry A. Kazakov
2009-06-26  8:39       ` Alex R. Mosteo
2009-06-26  9:07         ` Dmitry A. Kazakov
2009-06-27  9:53           ` Stephen Leake
2009-06-26 21:40         ` Randy Brukardt
2009-06-29 10:04           ` Alex R. Mosteo
2009-06-26  9:02       ` Stephen Leake
2009-06-26  9:14         ` Dmitry A. Kazakov
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox