From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,74dad3573c51736a X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII Received: by 10.68.59.229 with SMTP id c5mr718877pbr.6.1321992477317; Tue, 22 Nov 2011 12:07:57 -0800 (PST) Path: lh20ni6444pbb.0!nntp.google.com!news2.google.com!postnews.google.com!v38g2000prh.googlegroups.com!not-for-mail From: Adam Beneschan Newsgroups: comp.lang.ada Subject: =?windows-1252?Q?Re=3A_Basic_questions_about_wordings_in_=93Interfacing?= =?windows-1252?Q?_Pragmas=94?= Date: Tue, 22 Nov 2011 12:07:53 -0800 (PST) Organization: http://groups.google.com Message-ID: References: NNTP-Posting-Host: 66.126.103.122 Mime-Version: 1.0 X-Trace: posting.google.com 1321992477 29806 127.0.0.1 (22 Nov 2011 20:07:57 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Tue, 22 Nov 2011 20:07:57 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: v38g2000prh.googlegroups.com; posting-host=66.126.103.122; posting-account=duW0ogkAAABjRdnxgLGXDfna0Gc6XqmQ User-Agent: G2/1.0 X-Google-Web-Client: true X-Google-Header-Order: ARLUEHNKC X-HTTP-UserAgent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; WOW64; Trident/4.0; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.5.21022; .NET CLR 3.5.30729; .NET CLR 3.0.30618; .NET4.0C),gzip(gfe) Xref: news2.google.com comp.lang.ada:14527 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Date: 2011-11-22T12:07:53-08:00 List-Id: On Nov 22, 10:15=A0am, Yannick Duch=EAne (Hibou57) 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 shallno= t > > 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 =3D> "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 designat= ed 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 =A0The local_name in an interfacing pragma c= an 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 pragm= a > ? 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