From Keith.Bierman@eng.sun.com Tue Feb 28 08:43:56 1995 Received: from Sun.COM (koriel.Sun.COM) by dkuug.dk with SMTP id AA11522 (5.65c8/IDA-1.4.4j for ); Wed, 1 Mar 1995 01:48:17 +0100 Received: from Eng.Sun.COM (engmail2.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA12744; Tue, 28 Feb 95 16:47:37 PST Received: from chiba.Eng.Sun.COM by Eng.Sun.COM (5.x/SMI-5.3) id AA05530; Tue, 28 Feb 1995 16:44:21 -0800 Received: from localhost by chiba.Eng.Sun.COM (4.1/SMI-4.1) id AA04562; Tue, 28 Feb 95 16:43:57 PST Message-Id: <9503010043.AA04562@chiba.Eng.Sun.COM> To: maine@altair.dfrf.nasa.gov (Richard Maine) Cc: jwagener@amoco.com, SC22WG5@dkuug.dk Subject: Re: (SC22WG5.739) Re: In-Reply-To: Your message of "Tue, 28 Feb 95 14:31:03 +0800." <199502282231.AA06980@dkuug.dk> Date: Tue, 28 Feb 95 16:43:56 PST From: Keith.Bierman@eng.sun.com X-Charset: ASCII X-Char-Esc: 29 >1. Restrict the current consideration to C, though leaving open the > possibility of future expansion. This might tie down the problem The more general we make it, the harder it is. Less is sometimes more. >2. Use some extension of the f90 interface block. This seems like > an "obviously" good approach. At the moment, we lack datatypes which frequently appear in C. We need an unsigned. We need enums. We need C pointers. etc. I don't see that hiding this via magic interfaces blocks would be helpful (I am not against magic interface blocks, but first we need all the C datatypes). I am adverse to losing type-safety. If the user has been careful in C (used prototypes) and careful in fortran (used interface blocks) I want the processor(s) to be able to do type enforcement. I don't want to require it ;> Aside from the equivalent types, we need to establish a specific mapping. For example, for a C processor which provides float, double and long double we should establish (possibly via a standard module) kinds with useful names (perhaps c_float, c_double, c_long_double). For those unfamilar with c these are usually 32 and 64 bit values. long double can be the same as double, or is sometimes 128-bit. The thing to bear in mind, is what will a user have to cope with. The system docs will use C notation and will provide C include files. A vendor might choose to provide Fortran include files or perhaps modules. But even if a vendor doesn't any user can (if we make it within the realm of the reasonable). Things that exist in Fortran that are not in C (character* as we know it) need not concern us. Those that worry about C++ and Objective C "obvious" sucessors to C can rest assured that having all the datatypes and a defined mapping helps with those too. Of course more must be done to handle classes, etc. but that is work best deferred until there is a C++ standard rather than draft N of M. To whatever extent possible it would be kind of us to do this work early in the f2K cycle and to make the additional dataypes and whatever else available as a tech report for early implementation. However we must commit to not making incompatible changes after publication of the report, or we will have created incompatible existing practice to bite us later.