From maine@altair.dfrc.nasa.gov  Wed Jun  7 18:27:42 2000
Received: from mailhub.dfrc.nasa.gov (mailhub.dfrc.nasa.gov [130.134.81.12])
	by dkuug.dk (8.9.2/8.9.2) with ESMTP id SAA17689
	for <sc22wg5@dkuug.dk>; Wed, 7 Jun 2000 18:27:40 +0200 (CEST)
	(envelope-from maine@altair.dfrc.nasa.gov)
Received: from mail.dfrc.nasa.gov by mailhub.dfrc.nasa.gov with ESMTP; Wed, 7 Jun 2000 09:27:06 -0700
Received: from altair.dfrc.nasa.gov ([130.134.129.8]) by mail.dfrc.nasa.gov
          (Post.Office MTA v3.5.3 release 223 ID# 35-62055U1500L100S0V35)
          with ESMTP id gov for <sc22wg5@dkuug.dk>;
          Wed, 7 Jun 2000 09:27:07 -0700
Received: (from maine@localhost)
	by altair.dfrc.nasa.gov (8.9.3/8.9.3) id JAA06431;
	Wed, 7 Jun 2000 09:27:06 -0700
From: Richard Maine <maine@altair.dfrc.nasa.gov>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <14654.30682.115778.323834@altair.dfrc.nasa.gov>
Date: Wed, 7 Jun 2000 09:27:06 -0700 (PDT)
To: sc22wg5@dkuug.dk
Subject: (SC22WG5.1845) SC22WG5.1842) N1385 AFNOR proposal for August WG5 meeting
In-Reply-To: <200006071552.RAA17593@dkuug.dk>
References: <200006071552.RAA17593@dkuug.dk>
X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid

Malcolm Cohen <mjc@nag.co.uk> (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.  (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).  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.

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).

-- 
Richard Maine
maine@altair.dfrc.nasa.gov