From rz48@rz.uni-karlsruhe.de  Mon Apr 15 20:36:58 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 UAA21539 for <sc22wg5@dkuug.dk>; Mon, 15 Apr 1996 20:36:40 +0200
Received: from ry73.rz.uni-karlsruhe.de by nz11.rz.uni-karlsruhe.de 
          with SMTP (PP); Mon, 15 Apr 1996 19:53:44 +0200
Received: by ry73.rz.uni-karlsruhe.de (1.37.109.16/16.2) id AA231370823;
          Mon, 15 Apr 1996 19:53:43 +0200
Subject: TR-C straw vote on extern C data
To: sc22wg5@dkuug.dk
Date: Mon, 15 Apr 1996 19:53:42 +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: 3832
Message-ID: <"nz11.rz.un.305:15.04.96.17.54.45"@rz.uni-karlsruhe.de>

From:    Michael Hennecke
To:      WG5, X3J3
Subject: TR-C straw vote on extern C data
Date:    15-Apr-96

I would like to come to a decision how the TR on Interoperability should deal
with global C data objects, and would like to ask WG5 and X3J3 for a straw 
vote on this subject.

Actions/opinions until now varied quite a bit: the request for subdivision 
N1131 did not address the problem, N1147 provided the name-binding syntax for 
COMMON blocks, N1174 had that functionality moved out of the TR (into A.1.1),
and the X3J3/96-39 Liaison Report _required_ a mechanism to handle C externs,
with the recommendation not to use the COMMON mechanism. Some email discussion
is archived at http://www.uni-karlsruhe.de/~SC22WG5/TR-C/Email/ ...

There are currently three possible ways to deal with global C data objects:

1.  Use of COMMON:

    A  BIND(C,NAME="name-of-c-extern")  clause for a COMMON block 
    provides case-sensitive name binding to the name of the C extern,
    _and_ forces the layout of that COMMON block to match the C layout (new).

    The COMMON block holds a single variable of a type that corresponds
    to the type of the C extern. A COMMON block shall not be used with
    BIND(C) in some part of the program and without BIND(C) in others.

    Advantages:    Easy to implement (at this place only name binding added),
		   uses existing Fortran concepts for global data.
    Disadvantages: Builds on "obsolescent" language feature,
		   needs one COMMON for each C variable, 
		   with "dummy" names for Fortran local variables.

2.  Use of MODULE variables:

    A  BIND(C,NAME="name-of-c-extern")  clause as a new attribute for a
    (local) variable in the <specification-part> of a MODULE provides
    case-sensitive name binding to the name of the (global) C extern, 
    _and_ it indicates that storage for that object is allocated in a 
    C-generated object file and not in the MODULE.

    Such attribute is only allowed for objects of types that correspond
    to C types supported by the TR. The behavior in cases where different
    modules bind to the same C extern (and are accessible e.g. in different 
    parts of the same program) may be difficult to specify.

    Advantages:    "Natural" type declaration for the C variable (no COMMON),
		   Controlled access to the variable by USE association.
    Disadvantages: Users need to write a MODULE to have access to the
		   C extern (they may need one anyway for header-file infos),
		   Fortran local variable binds to a global data object,
		   new concept of storage for a static variable coming
		   from somewhere else (possibly difficult to implement).

3.  No specification how to access global C data in the TR

    Advantages:    More time (and more flexibility) to do it right in F2000
    Disadvantages: Possible limitations to use actual C code (examples???)

If there are no important applications which require the access of global C
data objects, my personal opinion would be to defer that problem to F2000
because using COMMON is not the ideal way to solve the problem, and using 
MODULE variables introduces new concepts that are perhaps too large for a TR.

Thanks,
Michael
 
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Straw vote: Treatment of C extern data objects in the TR on Interoperability 

I would prefer

  +---+
  |   |  to define a COMMON based method to access global C data objects.
  +---+
  |   |  to define a MODULE-variable based method to access global C data.
  +---+
  |   |  NOT to define facilities to access global C data objects in the TR.
  +---+

  Signed: ........................................

Please return to hennecke@rz.uni-karlsruhe.de, if possible until 19-Apr-96.

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx