Re: Basic questions about wordings in “Interfacing Pragmas”

[Adam Beneschan <adam@irvine.com>]

On Nov 22, 10:15 am, Yannick Duchêne (Hibou57)
<yannick_duch...@yahoo.fr> wrote:
> Hi people there,
>
> Some basic questions about some part of annexe B.1, Interfacing Pragmas.
>
> > 9.1/1 For pragmas Import and Export, the argument for Link_Name shallnot
> > be given without the pragma_argument_identifier unlessthe argument for
> > External_Name is given.
>
> What is that pragma_argument_identifier ? The Convention ?

As Christoph explained, the pragma_argument_identifier is either
External_Name or Link_Name.  The reason for this rule is simply that
the rule in B.1(5) (to be moved to Annex J) makes both the
External_Name and the Link_Name optional, the way the syntax rule is
written.  But if you said

   pragma Import (C, My_Proc, "your_proc");

Without any rule, there wouldn't be any way for the compiler to tell
whether "your_proc" is an External_Name or a Link_Name just from the
syntax rule.  So the rule was added that the string in the above is
always an External_Name, and if you want a Link_Name without an
External_Name you have to say

   pragma Import (C, My_Proc, Link_Name => "your_proc");

It's a lot simpler than the rule seems to make it appear.


> In legality rules> 18 T is an access-to-subprogram type, and its designated profile's
> > parameter and result types are all L-compatible.
>
> Why no similar wording for imported subprograms ? Was just forget or is
> this missing on purpose ? (or I missed it?)

This is part of the definition that starts at B.1(12): "If L is a
convention_identifier for a language, then a type T is said to be
compatible with convention L ... if ..."  Since this is talking about
a property of a type T, it wouldn't make sense to talk about imported
subprograms here.  B.1(26) gives the relevant rule about imported
subprograms.

>
> In notes at the bottom> 46 5  The local_name in an interfacing pragma can denote more
> > than one entity in the case of overloading. Such a pragma
> > applies to all of the denoted entities.
>
> Why not the same with types derived from a type with an interfacing pragma
> ?

Types can't be overloaded.  Since you can declare more than one
subprogram with the same name, the purpose of this note is to describe
what happens if you use that name in one of these pragmas, in that
case.  There's no need for a similar rule about types.


> Finally, what I was checking the RM for (related to the above), Static
> Semantics> 30 An interfacing pragma defines the convention of the entity denoted by
> > the local_name.
>
> So except if the type is tagged (as stated above), the convention is lost
> for any derived type [or] subtypes (as all are not anymore denoted by the
> same name the pragma was referring to) ?.

You may be confused about how subtypes and types work.  A "subtype" is
not a new type.  If you have a type T and a subtype S, and you declare
a variable "V : S", then V has subtype S *and* type T.  Similarly, if
you use S as a parameter

    procedure Proc (Param : in S);

then the parameter has *type* T as well has having *subtype* S.  So
when a rule like B.1(26) is applied to this procedure, and B.1(26)
speaks of parameter types, the type of this parameter is T, not S.

As for derived types: 13.1(15.3) says that representation information
is inherited for derived types, and these pragmas are representation
pragmas.  So no, the convention is not lost (as long as the pragma
comes before the derived type declaration).

                       -- Adam