pragma Convention questions

pragma Convention questions

[Samuel Tardieu]

I have several questions regarding pragma Convention in Ada95 for
language lawyers.

1- pragma Convention on private types in language-define packages

Is it allowed for a compiler implementor to use a pragma Convention
on a private type in a language-defined package?

For example, would it be allowed to use

  pragma Convention (C, chars_ptr);

in the private part of Interfaces.C.Strings? (the real motive to this
question is to get rid of a warning in GNAT about conversion between
pointers of different conventions -- the type is already compatible
with C as per RM B3.1(1))

2- pragma Convention, renaming and Intrinsic

Is the following code legal?

package U is
   type Foo is (Foo1, Foo2);
   function F return Foo renames Foo1;
   pragma Convention (Ada, F);
   type Foo_Access is access function return Foo;
   X : Foo_Access := F'Access;
end U;

GNAT rejects X initialization with 'prefix of "Access" attribute
cannot be intrinsic'. Which means that the pragma Convention failed
silently. Is it allowed to have it fail without a compilation error?
Or is the 'Access legal?

  Sam
-- 
Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/

Re: pragma Convention questions

[Martin Krischik]

Samuel Tardieu wrote:

> I have several questions regarding pragma Convention in Ada95 for
> language lawyers.

The language lawyers are on mailto: ada-comment@ada-auth.org ;-)
 
> 1- pragma Convention on private types in language-define packages
> 
> Is it allowed for a compiler implementor to use a pragma Convention
> on a private type in a language-defined package?
> 
> For example, would it be allowed to use
> 
>   pragma Convention (C, chars_ptr);

Yes. However the type must not be used beforehand - which is unlikely. Real
language lawyers can tell you the term after which a type can not have any
further modifications.
 
> in the private part of Interfaces.C.Strings? (the real motive to this
> question is to get rid of a warning in GNAT about conversion between
> pointers of different conventions -- the type is already compatible
> with C as per RM B3.1(1))
> 
> 2- pragma Convention, renaming and Intrinsic
> 
> Is the following code legal?
> 
> package U is
>    type Foo is (Foo1, Foo2);
>    function F return Foo renames Foo1;
>    pragma Convention (Ada, F);
>    type Foo_Access is access function return Foo;
>    X : Foo_Access := F'Access;
> end U;
> 
> GNAT rejects X initialization with 'prefix of "Access" attribute
> cannot be intrinsic'. Which means that the pragma Convention failed
> silently. Is it allowed to have it fail without a compilation error?
> Or is the 'Access legal?

This is a different problem. F does not actually exist and therefore has no
address to access. And for "Convention Ada" that's ok. What you really
meant to do is:

pragma Export (Ada, F);

But somehow I think that will fail because F does exists physically. Same
way you can do: 

enum Foo {Foo1, Foo2};
#define F Foo1
Foo *X = &F;

in C. (I take it you know C).

Martin

-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: pragma Convention questions

[Samuel Tardieu]

>>>>> "Martin" == Martin Krischik <krischik@users.sourceforge.net> writes:

Martin> Yes. However the type must not be used beforehand - which is
Martin> unlikely. Real language lawyers can tell you the term after
Martin> which a type can not have any further modifications.

Thank you, I know the freezing rules and they would not be
violated. My question was related to the legality of doing that when
I could not find the RM section which allows you to change the default
convention (Ada) of language-defined types (Interfaces.C.Strings.chars_ptr).

Martin> F does not actually exist and therefore has no address to
Martin> access. And for "Convention Ada" that's ok. What you really
Martin> meant to do is:

Martin> pragma Export (Ada, F);

I don't think so, pragma Convention should be enough. Note that
renaming an existing function instead of an enumeration literal
doesn't exhibit the same behaviour.

Martin> But somehow I think that will fail because F does exists
Martin> physically.

It doesn't exist physically because it inherits the convention of the
renamed entity (the enumeration literal, which has an Intrinsic
convention). That's precisely why I don't understand why GNAT lets me
specify its convention if it isn't able to honor it.

Note that the fact that an enumeration literal doesn't exist
physically as a function doesn't prevent you from using it as a
generic actual subprogram:

package W is
   generic
      with function F return Boolean;
   package Gen is end Gen;
   package Inst is new Gen (False);
end W;

(however, legality rules prevent you from ever taking a 'Access from
inside the generic as formal subprograms are not subtype conformant
with anything else, so my question would be void in this case)

The more I think about it the more I think GNAT should refuse the
pragma Convention, just as it refuses it if you try to apply it
directly to an enumeration literal. That's why I'd like some advice
here. I'll ask ada-comment, I hadn't thought about it, thanks.

Martin> I take it you know C

Yup, but there is no need to resort to an inferior language :)

  Sam
-- 
Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/

Re: pragma Convention questions

[Martin Krischik]

Samuel Tardieu schrieb:
>>>>>> "Martin" == Martin Krischik <krischik@users.sourceforge.net> writes:
> 
> Martin> Yes. However the type must not be used beforehand - which is
> Martin> unlikely. Real language lawyers can tell you the term after
> Martin> which a type can not have any further modifications.
> 
> Thank you, I know the freezing rules and they would not be
> violated. My question was related to the legality of doing that when
> I could not find the RM section which allows you to change the default
> convention (Ada) of language-defined types (Interfaces.C.Strings.chars_ptr).

I think the RM always stops at "private" leaving the implementer to do
whatever they want in the private section. I have seen private sections
full of pragma Import.

> Martin> F does not actually exist and therefore has no address to
> Martin> access. And for "Convention Ada" that's ok. What you really
> Martin> meant to do is:
> 
> Martin> pragma Export (Ada, F);
> 
> I don't think so, pragma Convention should be enough. Note that
> renaming an existing function instead of an enumeration literal
> doesn't exhibit the same behaviour.

I don't think so. Unless you export a function/procedure I would think
the function/procedure is fair game to be optimized away by a smart linker.

> Martin> But somehow I think that will fail because F does exists
> Martin> physically.
> 
> It doesn't exist physically because it inherits the convention of the
> renamed entity (the enumeration literal, which has an Intrinsic
> convention). That's precisely why I don't understand why GNAT lets me
> specify its convention if it isn't able to honour it.

Question is:

> Note that the fact that an enumeration literal doesn't exist
> physically as a function doesn't prevent you from using it as a
> generic actual subprogram:
> 
> package W is
>    generic
>       with function F return Boolean;
>    package Gen is end Gen;
>    package Inst is new Gen (False);
> end W;

But here F can be inline expanded - so intrinsic is ok.

> (however, legality rules prevent you from ever taking a 'Access from
> inside the generic as formal subprograms are not subtype conformant
> with anything else, so my question would be void in this case)
> 
> The more I think about it the more I think GNAT should refuse the
> pragma Convention, just as it refuses it if you try to apply it
> directly to an enumeration literal. That's why I'd like some advice
> here. I'll ask ada-comment, I hadn't thought about it, thanks.

I think you are right and it probably is a compiler bug.

Martin

-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: pragma Convention questions

[Samuel Tardieu]

>>>>> "Martin" == Martin Krischik <krischik@users.sourceforge.net> writes:

Martin> I don't think so. Unless you export a function/procedure I
Martin> would think the function/procedure is fair game to be
Martin> optimized away by a smart linker.

Unless you take a reference on it using 'Access :)

  Sam
-- 
Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/

Re: pragma Convention questions

[Adam Beneschan]

On Nov 11, 8:39 am, Samuel Tardieu <s...@rfc1149.net> wrote:
> I have several questions regarding pragma Convention in Ada95 for
> language lawyers.

> 2- pragma Convention, renaming and Intrinsic
>
> Is the following code legal?
>
> package U is
>    type Foo is (Foo1, Foo2);
>    function F return Foo renames Foo1;
>    pragma Convention (Ada, F);
>    type Foo_Access is access function return Foo;
>    X : Foo_Access := F'Access;
> end U;
>
> GNAT rejects X initialization with 'prefix of "Access" attribute
> cannot be intrinsic'. Which means that the pragma Convention failed
> silently. Is it allowed to have it fail without a compilation error?
> Or is the 'Access legal?

I think the Convention pragma should be illegal, although it takes a
bit of interpretation.  13.1(6) says, "If a local_name denotes a local
callable entity, it may do so through a local
subprogram_renaming_declaration (as a way to resolve ambiguity in the
presence of overloading); otherwise, the local_name shall not denote a
renaming_declaration."  This implies that, when you apply a
representation item (including Convention, see B.1(28)) to a renaming
subprogram, the semantics and rules are the same as if you had applied
them to the renamed entity.  Here, since there is no ambiguity, this
means that pragma Convention(Ada,F) should be exactly the same as
pragma Convention(Ada,Foo1), and the first should be illegal if the
second is illegal.  As to whether the language makes this illegal,
it's not 100% clear.  However, 6.3.1 divides subprograms into several
groups and defines the default calling convention for each group.
6.3.1(3) says, "The default calling convention for any subprogram not
listed below is Ada. A pragma Convention, Import, or Export may be
used to override the default calling convention (see B.1)."  Based on
how this section is structured, this could be taken to imply that this
is the *only* group for which the default calling convention can be
overridden.  An enumeration literal is not in this group (since it is
"listed below", 6.3.1(5)), and has a default convention of Intrisic;
based on this interpretation, it would mean that you may not apply a
Convention pragma to the enumeration literal---and therefore you may
not apply it to the function that renames the enumeration literal.

Anyway, that's my opinion on this matter; I could have easily missed
some relevant rule somewhere else.

                              -- Adam

Re: pragma Convention questions

[Samuel Tardieu]

>>>>> "Adam" == Adam Beneschan <adam@irvine.com> writes:

Adam> Anyway, that's my opinion on this matter; I could have easily
Adam> missed some relevant rule somewhere else.

Thanks Adam. This is an analysis very similar to the one I did
myself.

  Sam

Re: pragma Convention questions

[Randy Brukardt]

"Samuel Tardieu" <sam@rfc1149.net> wrote in message
news:87sl3cd9cw.fsf@willow.rfc1149.net...
> I have several questions regarding pragma Convention in Ada95 for
> language lawyers.
>
> 1- pragma Convention on private types in language-define packages
>
> Is it allowed for a compiler implementor to use a pragma Convention
> on a private type in a language-defined package?

I would say that is not allowed, because it could cause portability problems
between implementations. But I don't have any RM reference for that opinion,
so if you really care you'll need to ask on Ada-Comment. Also:

> For example, would it be allowed to use
>
>   pragma Convention (C, chars_ptr);
>
> in the private part of Interfaces.C.Strings? (the real motive to this
> question is to get rid of a warning in GNAT about conversion between
> pointers of different conventions -- the type is already compatible
> with C as per RM B3.1(1))

I think in this case, you could never tell the difference, so it would be OK
to do. (One wonders why the Standard didn't include that in the first
place.)

> 2- pragma Convention, renaming and Intrinsic
>
> Is the following code legal?
>
> package U is
>    type Foo is (Foo1, Foo2);
>    function F return Foo renames Foo1;
>    pragma Convention (Ada, F);
>    type Foo_Access is access function return Foo;
>    X : Foo_Access := F'Access;
> end U;
>
> GNAT rejects X initialization with 'prefix of "Access" attribute
> cannot be intrinsic'. Which means that the pragma Convention failed
> silently. Is it allowed to have it fail without a compilation error?
> Or is the 'Access legal?

I think that it should either work or the pragma Convention should be
rejected. To allow the change of the convention to one that is legal and
still reject the 'Access is bogus. (OTOH, this doesn't seem like a very
important bug, and I would not be surprised if it took a long time to get
fixed.)

                                   Randy.

Re: pragma Convention questions

[Samuel Tardieu]

>>>>> "Randy" == Randy Brukardt <randy@rrsoftware.com> writes:

Randy> I think in this case, you could never tell the difference, so
Randy> it would be OK to do. (One wonders why the Standard didn't
Randy> include that in the first place.)

Thank you. It is now fixed in GCC sources.

>> GNAT rejects X initialization with 'prefix of "Access" attribute
>> cannot be intrinsic'. Which means that the pragma Convention failed
>> silently. Is it allowed to have it fail without a compilation
>> error?  Or is the 'Access legal?

Randy> I think that it should either work or the pragma Convention
Randy> should be rejected. To allow the change of the convention to
Randy> one that is legal and still reject the 'Access is bogus. (OTOH,
Randy> this doesn't seem like a very important bug, and I would not be
Randy> surprised if it took a long time to get fixed.)

This is free software after all: I added a fix yesterday into the GCC
source tree :)

  Sam
-- 
Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/