From robert.corbett@eng.sun.com Thu Jun 8 04:07:10 2000 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by dkuug.dk (8.9.2/8.9.2) with ESMTP id EAA19080 for ; Thu, 8 Jun 2000 04:07:09 +0200 (CEST) (envelope-from robert.corbett@eng.sun.com) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA27403; Wed, 7 Jun 2000 19:07:08 -0700 (PDT) Received: from ha-sims.eng.sun.com (phys-thestorka.Eng.Sun.COM [129.146.1.231]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id TAA13454; Wed, 7 Jun 2000 19:07:07 -0700 (PDT) Received: from lupa (lupa.Eng.Sun.COM [129.146.78.104]) by ha-sims.eng.sun.com (Sun Internet Mail Server sims.4.0.1999.06.13.00.20) with SMTP id <0FVT00MD5CJUPF@ha-sims.eng.sun.com>; Wed, 7 Jun 2000 19:07:06 -0700 (PDT) Date: Wed, 07 Jun 2000 19:07:06 -0700 (PDT) From: Robert Corbett Subject: Re: (SC22WG5.1846) SC22WG5.1842) N1385 AFNOR proposal for August WG5 meeting To: maine@altair.dfrc.nasa.gov Cc: sc22wg5@dkuug.dk Reply-to: Robert Corbett Message-id: <0FVT00MD6CJUPF@ha-sims.eng.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4u sparc Content-type: TEXT/plain; charset=us-ascii Content-MD5: USxcSxLn1oOuu1+me2X9zw== > Malcolm Cohen (local) writes: > > > Never mind BACKSPACE, 'XDR_UNFORMATTED' cannot even handle READ! > ... > > i.e. if we want to make XDR_UNFORMATTED look like UNFORMATTED we have to write > > record markers. If, as Robert Corbett implies, it has none, then we need to > > define a whole new kind of i/o file. > > And then there are derived types. I don't know what XDR says about > such things. XDR handles, structures, discriminated unions, and opaque types. > (If we did do anything even vaguely like this, we'd > certainly need to add a normative reference instead of just assuming > that the name was sufficient citation, though I presume that a > suitable citable reference would be easy enough to find). It is currently RFC 1832. It was recently upgraded from a proposed internet standard to a draft internet standard (one step below an internet standard). > But Fortran > currently says quite a bit about unformatted files. Including such > things as that writing an object of derived type to an unformatted > file is not the same thing as writing the components. Does XDR even > have provision for derived types, or is it just presumed that they > will be decomposed into components? I suppose I ought to know the > answer to that, but I'm afraid I don't. XDR provides for structured data. > And presumably one would want to disallow the combination of > 'xdr_unformatted' and access='direct'. I don't recall whether the > proposed edits remembered to do that. > > I'll confess to knowing too little about XDR to know what other issues > might lurk. For example, might the processor support precisions > other than ones defined in XDR? If so, what would we need to say > about that? > > All doable, I'm sure. But I seriously doubt you are going to fit it > on one page of edits, or even particularly close. I'd think that, as > Malcolm says, you'd be talking a new kind of form, or at least a > comparable amount of edits (and more importantly, a comparable amount > of thought to its interactions). An important consideration is the goal of the effort. If the intent is to provide a way to allow data to be transferred between heterogeneous Fortran processors, the extension needed is small. I assume that is what AFNOR wants. If support for XDR is wanted as a first step toward supporting internet services that depend on XDR, the extension needed is huge. I assume that is not what AFNOR wants. Sincerely, Bob Corbett