From zongaro@VNET.IBM.COM  Tue Jul 16 16:55:57 1996
Received: from VNET.IBM.COM (vnet.ibm.com [199.171.26.4]) by dkuug.dk (8.6.12/8.6.12) with SMTP id QAA13080 for <sc22wg5@dkuug.dk>; Tue, 16 Jul 1996 16:55:54 +0200
Received: from TOROLAB by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 8026;
   Tue, 16 Jul 96 10:55:53 EDT
Received: by TOROLAB (XAGENTA 4.0) id 4244; Tue, 16 Jul 1996 10:53:09 -0400 
Received: by twinpeaks.torolab.ibm.com (AIX 3.2/UCB 5.64/4.03)
          id AA19106; Tue, 16 Jul 1996 10:54:56 -0400
From: <zongaro@VNET.IBM.COM> (Henry Zongaro)
Message-Id: <9607161454.AA19106@twinpeaks.torolab.ibm.com>
Subject: Re: (SC22WG5.1125) C Interoperability
To: hennecke@rz.uni-karlsruhe.de
Date: Tue, 16 Jul 1996 10:54:54 -0400 (EDT)
Cc: sc22wg5-interop@ncsa.uiuc.eud, sc22wg5@dkuug.dk
In-Reply-To: <199607101717.TAA20125@dkuug.dk> from "Michael Hennecke" at Jul 10, 96 06:57:47 pm
X-Mailer: ELM [version 2.4 PL24alpha3]
Content-Type: text
Content-Length: 2924

Hi Michael,

> I would like to ask for input on the interoperability TR once again.
>
> Documents N1184 (X3J3/96-118) and N1185 (X3J3/96-119) have been sent to
> the WG5 and X3J3 mailing lists about one month ago, and are now also
> available from the WG5 ftp server. I received two small replies on N1184
> and _no_ comment on N1185. There has been _no_ contribution to the TR-C
> mailing list for the last two months (except for N1184 and N1185).
>
> Given this situation, it is unlikely that the TR will be completed timely
> (in either the current direction or the one currently favoured by X3J3).
> As long as the issues raised in X3J3's last liaison report (X3J3/96-106r1)
> are not resolved, it is unreasonable to further develop the document at all.
> It would be very helpful if X3J3 and WG5 members could state their opinion
> on my answers to these issues (in N1184 and N1185) before or during the
> Dresden meeting.
>
> Apart from this, I recently received two interesting pointers from the
> Ada and Modula-2 communities which do also address C interoperability:
>
>  http://lglwww.epfl.ch/Ada/LRM/9X/rm9x/rm9x-B.html     (Ada95, Annex B)
>  ftp://dutiba.twi.tudelft.nl/pub/wg13/d228/d228.ps.gz  (Modula-2 draft TR)

     I've made it clear before that I'm in general in agreement with the
direction of the interoperability TR as opposed to the direction of the
"MAP_TO" approach described by HPFF, that is currently favoured by X3J3.
I'm also in agreement with the content of N1185, with one small exception.

     In section (V) of N1185, you've made some suggestions about permitting
mismatching arguments in F2000 in order to perform conversions at procedure
calls, rather than relying on MAP_TO to do this.

     After a little bit of thinking on this, I realized something that I don't
think anyone has mentioned about this issue before.  What happens when the
precision of the type specified for the dummy argument is different from the
precision of the type to which we are mapping?

      PROGRAM P
        INTERFACE
          EXTRINSIC(C) SUBROUTINE C_SUB(R)
            ! Note, that the syntax has changed
            REAL(KIND(0.0D0)), MAPTO('FLOAT', 'REF') :: R
          END SUBROUTINE C_SUB
        END INTERFACE

        REAL(KIND(0.0D0)) :: R

        R = 1.0D0 + 5.0D-10
        PRINT *, R
        CALL C_SUB(R)
        PRINT *, R
      END PROGRAM P

      void c_sub(float *r)
      {
      }

If the C type float has lower precision than does the real type with kind type
parameter equal to KIND(0.0D0), the value of R could be altered by the call to
C_SUB, even if c_sub never modifies *r.  So this program might print

 1.00000000050000004
 1.00000000000000000

     Perhaps this was obvious to everyone but me, but I think this is something
that is another potential pitfall for users of a "MAP_TO" facility, and that it
should be avoided even in Fortran 2000.

Thanks,

Henry