From rz48@rz.uni-karlsruhe.de  Sat Apr 20 14:33:12 1996
Received: from nz11.rz.uni-karlsruhe.de (nz11.rz.uni-karlsruhe.de [129.13.64.7]) by dkuug.dk (8.6.12/8.6.12) with ESMTP id OAA03007 for <sc22wg5@dkuug.dk>; Sat, 20 Apr 1996 14:33:10 +0200
Received: from ry73.rz.uni-karlsruhe.de by nz11.rz.uni-karlsruhe.de 
          with SMTP (PP); Sat, 20 Apr 1996 14:32:02 +0200
Received: by ry73.rz.uni-karlsruhe.de (1.37.109.16/16.2) id AA005883520;
          Sat, 20 Apr 1996 14:32:00 +0200
Subject: TR-C result of straw-vote
To: sc22wg5@dkuug.dk
Date: Sat, 20 Apr 1996 14:31:59 +0200 (CES)
Cc: sc22wg5-interop@ncsa.uiuc.edu
From: hennecke@rz.uni-karlsruhe.de
X-Mailer: ELM [version 2.4 PL23]
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit
Content-Length: 3085
Message-ID: <"nz11.rz.un.906:20.04.96.12.32.03"@rz.uni-karlsruhe.de>

The result of the straw vote on extern C data objects until
Sat Apr 20 14:00 CES 1996 is

  (2-11-4)  for  (COMMON-MODULE-DEFER)

(counting two objecting common and undecided on the last two as (0-1-1)).
I might also note that 2.5 of the DEFER votes come from the heads of 
WG5/Interop, X3J3/Interop, and the F95 project editor.

The full set of comments is available from the TR-C web site, I'd like to
comment on three of them here: 


> Dick Hendrickson (NO on COMMON):
> We should not add new features to storage association.
Because the C variable is a global data object, we need to ensure that there
isn't any actual storage association _even_ with MODULE variables, which until
now are local. It might be harder to ensure that then living with COMMON.
See also first Reid comment below.


> John Reid (MODULE):
> I think there must be a restriction that only one module binds
> to any particular C object.
Definitely. There are also many other things to be forbidden, like
initialization. SAVE will be implied. Occurence in COMMON and EQUIVALENCE
should be forbidden, etc.
>                             You could require that if a module has such
> a binding, all objects in the module do.
I don't think that's a good idea because there may be many cases where a
module translates a "c_source.h" header, and it might be handy to introduce
local Fortran variables/procedures there to facilitate that translation.
>                                          You could even require that
> all such bindings reside in a single module.
No. The maximim may be all such bindings for one C translation unit
(or header file) reside in one module. 
Otherwise the whole thing will become unmanageable.


> Craig T. Dedo (MODULE):
>     I do NOT believe that we should delay such a feature until Fortran 2000.  
> I very much fear that such a delay may make the interoperability feature 
> impractical to use for important real world applications (e.g. calling to the 
> MS Windows API).  I would be willing to support a delay only if a rigorous, 
> thorough investigation revealed that there are no important uses for this 
> feature.
Could you provide an example of a real world application's global C data 
object you need to access from Fortran, like from the MS Windows API?
Note that N1152 requires the demand for a feature to be proven, not vice versa.


I will put a MODULE variable solution in the next draft (low priority),
but with the option to drop it if that's too difficult.

Best regards,
Michael

 ======================================================================
  Michael Hennecke      http://www.uni-karlsruhe.de/~Michael.Hennecke/ 
 ----------------------------------------------------------------------
  University of Karlsruhe         RFC822: hennecke@rz.uni-karlsruhe.de 
  Computing Center (G20.21 R210)           BITNET: RZ48@DKAUNI2.BITNET 
  Zirkel 2  *  P.O. Box 69 80                 Phone: +49 721  608-4862 
  D-76128  Karlsruhe                               Fax: +49 721  32550 
 ======================================================================