From owner-sc22wg5@open-std.org  Wed Jan 21 20:56:20 2009
Return-Path: <owner-sc22wg5@open-std.org>
X-Original-To: sc22wg5-dom7
Delivered-To: sc22wg5-dom7@www2.open-std.org
Received: by www2.open-std.org (Postfix, from userid 521)
	id 122C3C178E0; Wed, 21 Jan 2009 20:56:20 +0100 (CET)
X-Original-To: sc22wg5@open-std.org
Delivered-To: sc22wg5@open-std.org
X-Greylist: delayed 1708 seconds by postgrey-1.18 at www2.open-std.org; Wed, 21 Jan 2009 20:56:19 CET
Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21])
	by www2.open-std.org (Postfix) with ESMTP id 2814DC178D9
	for <sc22wg5@open-std.org>; Wed, 21 Jan 2009 20:56:18 +0100 (CET)
Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31])
	by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n0LJRhgx013783;
	Wed, 21 Jan 2009 19:27:43 GMT
Received: from ranma.sfbay.sun.com (ranma.SFBay.Sun.COM [129.146.84.89])
	by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n0LJRhWo018446;
	Wed, 21 Jan 2009 11:27:43 -0800 (PST)
Received: (from michaeli@localhost)
	by ranma.sfbay.sun.com (8.11.7p1+Sun/8.11.7) id n0LJRhB24072;
	Wed, 21 Jan 2009 11:27:43 -0800 (PST)
Date: Wed, 21 Jan 2009 11:27:43 -0800 (PST)
From: Michael Ingrassia <michaeli@ranma.sfbay.sun.com>
Message-Id: <200901211927.n0LJRhB24072@ranma.sfbay.sun.com>
To: sc22wg5@open-std.org, mpi3-fortran@lists.mpi-forum.org,
	j3@j3-fortran.org
Subject: Re: (j3.2006) (SC22WG5.3864) [MPI3 Fortran] MPI non-blocking transfers
X-Sun-Charset: US-ASCII
Sender: owner-sc22wg5@open-std.org
Precedence: bulk


> I do 
>not know whether in F2003 the interface of a procedure has to specify 
>ASYNCHRONOUS if the dummy gets it implicitly

Fascinating.  I think yes.

The relevant provisions seem to be

12.3.1.1 [04-007:page257]
"A procedure ... shall have an explicit interface if it is reference and ...
The procedure has a dummy argument that (a) has the ... ASYNCHRONOUS ...
attribute"

and

5.1.2.3 [04-007:page77] "The ASYNCHRONOUS attribute may be conferred implicitly 
by the use of a variable in an asynchronous input/output statement."

and

12.2.1.1 [04-007:page256]  "The characteristics of a dummy data object are its type,...whether it has the ... ASYNCHRONOUS ... attribute[s]"


and

12.3 "The characteristics of a procedure are fixed ... in different scoping
units"

So in order that an interface block not be a scoping unit
in which a dummy argument had different characteristics than the actual
procedure, I think the standard does require that the ASYNCHRONOUS attribute
be explicitly conferred on the dummy argument.  That is, 
unless someone can figure
out a way to give it the ASYNCHRONOUS attribute implicitly in an interface
block; for all I remember we may have introduced a way to smuggle
an asynchronous input/output statement into a type declaration.

	--Michael I.