From JKR@ib.rl.ac.uk Fri Jun 19 18:34:18 1992
Received: from danpost2.uni-c.dk by dkuug.dk via EUnet with SMTP (5.64+/8+bit/IDA-1.2.8)
	id AA13650; Fri, 19 Jun 92 18:34:18 +0200
Received: from vm.uni-c.dk by danpost2.uni-c.dk (5.65/1.34)
	id AA13372; Fri, 19 Jun 92 18:32:38 +0200
Received: from vm.uni-c.dk by vm.uni-c.dk (IBM VM SMTP V2R1) with BSMTP id 8364;
   Fri, 19 Jun 92 18:34:34 DNT
Received: from UKACRL.BITNET by vm.uni-c.dk (Mailer R2.07) with BSMTP id 8570;
 Fri, 19 Jun 92 18:34:33 DNT
Received: from RL.IB by UKACRL.BITNET (Mailer R2.07) with BSMTP id 1358; Fri,
 19 Jun 92 17:33:49 BST
Received: from RL.IB by UK.AC.RL.IB (Mailer R2.07) with BSMTP id 4916; Fri, 19
 Jun 92 17:33:47 BST
Via:        UK.AC.RL.IB; 19 JUN 92 17:33:45 BST
Message-Id: <19 Jun 92 17:29:30 BST JKR@UK.AC.RL.IB>
Date:       Fri, 19 Jun 92 17:29:30 BST
From: "JKR" (JKR at UKACRL) <JKR@ib.rl.ac.uk>
To: SC22WG5@dkuug.dk
Subject:    Clarifications and corrections to ISO/IEC 1539
X-Charset: ASCII
X-Char-Esc: 29

Here is a copy of a paper that has been sent to Jeanne for the
Victoria premeeting distribution.

..............................................................

To: WG5
From: BSI Fortran panel
Subject:  Clarifications and corrections to ISO/IEC 1539 : 1991 (E)
Date: 19 June 1992

Introduction

It is inevitable that a document such as ISO/IEC 1539 will contain
errors and ambiguities. Anyone who has written a book will understand
that if you want to get it out of the door in a timely fashion, some
are inevitable. Remarkably few have come to light in this case.
Nevertheless, WG5 has a responsibility to the community of compiler
writers to 'maintain' the standard, so that they know exactly what is
required of them. The BSI group therefore proposes that a document of
'clarifications and corrections' be officially adopted at Victoria and
have asked for agenda time. The intention is that it be issued by ISO
as an annex to the standard. Attached is a first draft, obtained from
S20.120 by looking for items that require changes to the standard and
which appear to be non-controversial. We will revise it in the light of
S20.121 as soon as this is available.

The references to S20 are for the convenience of WG5 and will be
omitted from the final version.

...............................................................

Annex. Clarifications and corrections.

(S20/15) Page 33, line 36. Replace the fourth constraint for R429 by:

    Constraint: The character length specified by the <char-length> in
	 a <component-decl> or the <char-selector> in a <type-spec>
	 (5.1, 5.1.1.5) must be a constant specification expression
         (7.1.6.2).


(S20/16) Page 42, lines 29-33. Replace the text following the
       constraints for R508 by:

         The <char-selector> in a CHARACTER <type-spec> and the
         * <char-length> in an <entity-decl> or in a <component-decl>
         of a type definition specify character length. The *
         <char-length> in an <entity-decl> or <component-decl> specifies
         an individual length and overrides the length specified in the
         <char-selector>, if any. If a * <char-length> is not specified
         in an <entity-decl> or <component-decl>, the <length-selector>
         or <type-param-value> specified in the <char-selector> is the
         character length. If the length is not specified in a
          <char-selector> or a * <char-length>, the length is 1.


(S20/27) Page 199, line 3+. Add the new paragraph:

         For POINTER and TARGET to be currently associated, they must
         have the same type, type parameters, and rank. In the array
         case, they must have the same shape and bounds, and
         corresponding array elements, in array element order, must
         be associated.