From rz48@rz.uni-karlsruhe.de  Wed Jul 31 19:31:57 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 TAA07599 for <SC22WG5@dkuug.dk>; Wed, 31 Jul 1996 19:31:47 +0200
Received: from ry20.rz.uni-karlsruhe.de by nz11.rz.uni-karlsruhe.de 
          with SMTP (PP); Wed, 31 Jul 1996 15:29:03 +0200
Received: from ry71.rz.uni-karlsruhe.de by ry20.rz.uni-karlsruhe.de 
          with SMTP (1.36.108.7/16.2) id AA12527;
          Wed, 31 Jul 1996 15:28:56 +0200
Subject: N1214
To: SC22WG5@dkuug.dk
Date: Wed, 31 Jul 1996 15:28:55 +0200 (CES)
Cc: sc22wg5-interop@ncsa.uiuc.edu
From: hennecke@rz.uni-karlsruhe.de (Michael Hennecke)
Reply-To: hennecke@rz.uni-karlsruhe.de (Michael Hennecke)
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: 2317
Message-ID: <"nz11.rz.un.212:31.07.96.13.34.35"@rz.uni-karlsruhe.de>


                                                   ISO/IEC JTC1/SC22/WG5/N1214

                                                                     25-Jul-96
 
  To:         WG5
  From:       WG5/Interop
  Subject:    TR-C subgroup report
  References: WG5/N1178(X3J3/96-069), WG5/N1185(X3J3/96-119),
              X3J3/96-106r1, X3J3/95-295.


  At the Dresden meeting, WG5/Interop investigated most of the outstanding
  technical issues of the interoperability report N1178, as well as the 
  option to include a MAP_TO conversion facility into the TR. 
  As a result of this work, the following conclusions can be made:


  (1) /Interop recommends to add a MAP_TO facility for automatic conversion
      of the type and/or kind of data objects of basic types, along the lines
      of X3J3/95-295. This would enhance the current facilities (KIND 
      parameters for C datatypes) and diminuish the current divergence of the 
      ISO and HPFF interoperability approaches.


  (2) /Interop thinks that regardless of the type mapping mechanism for 
      structure components (KINDs or MAP_TO), there is a need for a layout 
      clause like BIND(C) inside the TYPE definition for a C struct.


  (3) /Interop recommends that C character strings be mapped to Fortran 
      CHARACTER(LEN=1) arrays as proposed in X3J3/96-106r1.


  (4) /Interop feels that a <type-alias-stmt>, which only establishes a new
      name for an existing type, does not have significant impact on
      other features of the language. It is aware of the fact that the
      current <type-alias-stmt> is not able to model ALL possible C typedef 
      constructs, but only those with a well-defined meaning in Fortran.


  (5) Interfacing to operating system facilities is often dependent on the
      possibility to access global variables defined in these interfaces.
      Therefore, /Interop would like to express the necessity to provide 
      a binding to C extern data objetcs.


  (6) /Interop concurs with the issues raised in N1185 about MAP_TO and
      struct mappings. Therefore, it does not recommend a "recursive mapto".
      Nevertheless, the TR-C development body is encouraged to investigate 
      alternative possibilities to specify MAP_TO conversion, e.g. at the 
      specification of structure components.