[MPI3 Fortran] Proposing changes to Fortran 2008

Aleksandar Donev donev1 at llnl.gov
Tue Mar 18 12:18:52 CDT 2008


On Tuesday 18 March 2008 06:56, Craig Rasmussen wrote:

> Why can't c_void be used like c_ptr is now so that the interface is  
> bi-directional (implementable in either C or Fortran)?
Because entities in Fortran must have a type----the standard literally breaks 
down otherwise. CLASS(*) is the Fortran (2003) "equivalent" to void*, but it 
does have a (dynamic) type. The type is passed in a "type descriptor". If 
there is no type info, but rather just an address, you can't do anything to 
it in Fortran and you cannot interpret the meaning of the standard. And the 
committee will never go along with changing the standard to allow such a 
thing and thus make Fortran look like C :-)

> Unfortunately the integer declaration is just for show also.  What is  
> really meant in
>         void :: buffer
> and everything else is just to get around the fact we can't have a  
> void type in Fortran.
You are agreeing with me that one should not be specifying false attributes 
and fake types and then ignoring them. It is a hack unsuitable for 
standardization.

But, the problem I see with the above declaration (which I find very nice) is 
that it requires (significantly) more work to add to the standard. One has to 
specify a whole new section about argument matching for such "void" 
arguments. This includes issues such as what the dummy is actually associated 
with (the whole of the actual in array-element order?), whether the actual 
needs to be an array or scalar or either, what type it may have, whether it 
has to be contiguous, whether copy in/out is ever allowed or not, etc., etc. 
I can help you write a draft of such rules. But, it won't be easy to push it 
through the committee, especially at this stage.

My idea is to only allow type mismatch, much like we do for CLASS(*) dummies 
but just passing an address without a type descriptor. This is a much more 
localized change. Dealing with multiple ranks is also useful but IMO not 
crucial and requires more work.

Or, one can propose both during the comment period and let J3 make an opinion.
In any case, I strongly urge the MPI Forum Fortran group to come up with a 
proposal for the May J3 meeting to get the ball rolling early.

Best,
Aleks

-- 
Aleksandar Donev, Ph.D.
Lawrence Postdoctoral Fellow @ Lawrence Livermore National Laboratory
High Performance Computational Materials Science and Chemistry
E-mail: donev1 at llnl.gov
Phone: (925) 424-6816  Fax: (925) 423-0785
Address: P.O.Box 808, L-367, Livermore, CA 94551-9900
Web: http://cherrypit.princeton.edu/donev




More information about the mpiwg-fortran mailing list