From owner-sc22docs@open-std.org  Tue Jul 18 16:13:04 2006
Return-Path: <owner-sc22docs@open-std.org>
X-Original-To: sc22docs-domo3
Delivered-To: sc22docs-domo3@open-std.org
Received: by open-std.org (Postfix, from userid 521)
	id 1210A152CA; Tue, 18 Jul 2006 16:13:03 +0200 (CET DST)
X-Original-To: sc22info@open-std.org
Delivered-To: sc22docs@open-std.org
Received: from 0e0mail1.ansi.org (outbound.ansi.org [12.15.192.5])
	by open-std.org (Postfix) with ESMTP id 150021212B
	for <sc22info@open-std.org>; Tue, 18 Jul 2006 16:12:57 +0200 (CET DST)
Received: by EMAIL1 with Internet Mail Service (5.5.2653.19)
	id <33SNSWFQ>; Tue, 18 Jul 2006 10:09:36 -0400
Message-ID: <FEEA109B01A4D7118B6000D0B7C9E30606231B7E@EMAIL1>
From: Sally Seitz <SSeitz@ansi.org>
To: sc22info@open-std.org
Subject: N 4082-Defect Report 2 for ISO/IEC 1539-1: 2004, Programming lang
	uages - Fortran
Date: Tue, 18 Jul 2006 10:09:34 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C6AA73.CC113FA2"
Sender: owner-sc22docs@open-std.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C6AA73.CC113FA2
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

ISO/IEC JTC 1/SC22
Programming languages, their environments and system software =
interfaces
Secretariat:=A0 U.S.A.=A0 (ANSI)=20
=A0=20
ISO/IEC JTC 1/SC22 N4082
=A0=20
TITLE:=20
Defect Report 2 for ISO/IEC 1539-1: 2004, Programming languages - =
Fortran

DATE ASSIGNED:=20
2006-07-17
=A0=20
SOURCE:=20
SC 22/WG 5 Convener (J. Reid)

BACKWARD POINTER:=20
N/A=20
=A0=20
DOCUMENT TYPE:=20
Defect Report
=A0
PROJECT NUMBER:=20

=A0=20
STATUS:=20
For information and review when voting on N 4080.

ACTION IDENTIFIER:=20
FYI
=A0=20
DUE DATE:=20
=A0=20
DISTRIBUTION:=20
TEXT

CROSS REFERENCE:=20
=A0=20
DISTRIBUTION FORM:=20
Def=20

_________end of cover sheet, beginning of document___________

ISO/IEC JTC1/SC22/WG5 N1666
Defect Report 2 for Fortran 2003

All edits specified in this document relate to WG5-N1601 (j3/04-007).
Other references to page and line numbers in general refer to the
standard document as it was at the time of the initial interpretation
request and/or subsequent interpretation work.

----------------------------------------------------------------------
  =20
NUMBER: F03/0008
TITLE: Pointer assignment and arrays
KEYWORDS: pointer assignment, array, data-ref
DEFECT TYPE: Erratum
STATUS: Passed by WG5 ballot

QUESTION:

There appears to be no explicit requirement that the
<variable>s in R736 and R741 be scalar.  If data-pointer-object
and proc-component ref were data-refs, then C614 would prohibit
the <variable>s from being arrays.  However, although the syntax
looks like a special case of a data-ref, nothing appears to say
that R736 and R741 actually constitute data-refs.

The standard gives no interpretation as to what the meaning
would be in the case of an array.

Even when variable is a scalar, the standard does not appear to
define what the properties (such as type and shape) of a
data-pointer-object or proc-pointer-object are in the case where
the syntax has a "%".  All we have is a syntax with no
established meaning.

Q1. Is the <variable> in R736 or R741 allowed to be an array?

Q2. Is the interpretation of the forms in R736 and R741 the
    same as that of a data-ref?

ANSWER:

A1. No.  The standard provides no interpretation of what such
    a form would mean.  Therefore, by the first sentence of
    1.5, it is not standard-conforming.  Edits are provided to
    make this prohibition more direct.

A2. Yes.

EDITS:

All edits refer to 04-007.

[143:12,24,35,37] Insert "<scalar->" before "<variable>", four times.

SUBMITTED BY: Richard Maine

HISTORY: 04-333    m169  F03/0008 Submitted
         04-333r1  m169  Passed by J3 meeting
         04-418r1  m170  Failed J3 letter ballot #9
         04-421    m170  Revised - Passed by J3 meeting
         05-146    m171  Passed J3 letter ballot #10
         N1658     m176  Passed WG5 ballot N1657
         N1663           Reaffirmed in WG5 ballot N1661 on N1660

----------------------------------------------------------------------

NUMBER: F03/0012
TITLE:  Procedure pointers and the EXTERNAL attribute
KEYWORDS: Procedure pointers, EXTERNAL
DEFECT TYPE: Erratum
STATUS: Passed by WG5 ballot

QUESTION:

Is the following program unit standard conforming?

  SUBROUTINE SUB ( RPP )
    REAL, EXTERNAL, POINTER :: RPP
    EXTERNAL :: PP
    POINTER :: PP
    PROCEDURE(REAL), POINTER :: PPP =3D> NULL()
  END SUBROUTINE SUB

The last sentence of "5.1.2.6 EXTERNAL attribute" appears to indicate
that it is allowed:

  "A procedure that has both the EXTERNAL and POINTER attributes is a
  procedure pointer."

That the title of subclause 12.2.1.2 is "Characteristics of dummy
procedures and dummy procedure pointers" suggests that it is allowed.
That subclause continues "... whether it is a pointer, ..." so it was
clearly envisioned that at least dummy procedures could have the
POINTER attribute.

C1216 [264:30] appears to require PPP to be allowed:

"C1216 (R1214) If =3D> appears in <proc-decl>, the procedure entity
       shall have the pointer attribute."

On the other hand, A conspiracy of C512 [72:28-29]

"C512 (R501) If the POINTER attribute is specified, the ALLOCATABLE,
      TARGET, EXTERNAL, or INTRINSIC attribute shall not be
      specified."

the second sentence of subclause 5.1.2.6 [80:38-40]

  "This [EXTERNAL] attribute may also be specified by ... a
  <procedure-declaration-stmt>..."

the first paragraph of subclause 5.2 [85:15ff]

  "The combination of attributes that may be specified for a
   particular entity is subject to the same restrictions ...
   regardless of the method of specification.  This also applies to
   the PROCEDURE, EXTERNAL and INTRINSIC statements."

and the last sentence of the first paragraph of 12.3.2.3 [264:8]

  "It [the procedure declaration statement] specifies the EXTERNAL
  attribute...."

appears to completely wipe out procedure pointers (PPP because of the
first paragraph of 12.3.2.3).

C521 [73:6-7] and C568 [91:5] also appear to prohibit RPP and PP:

"C521 (R504) The <function-name> shall be the name of an external
      function, a function dummy procedure{, or a statement
      function}."

"C568 (R541) A <proc-entity-name> shall also be declared in a
      <procedure-declaration-stmt>."

But then the first paragraph after R1210 (defining the EXTERNAL
statement) [264:1] appears to allow RPP and PP:

  "Each <external-name> shall be the name of ... a procedure
   pointer...."

There is also a problem with protected procedure pointers.  C535
clearly envisions their existence:

"C535 (R501) The PROTECTED attribute is permitted only for a procedure
      pointer...."

while C536 prohibits their existence:

"C536 (R501) If the PROTECTED attribute is specified, the EXTERNAL ...
      attribute shall not be specified."

ANSWER:

The discussion of procedure pointers is indeed inconsistent.

The program unit is intended to be standard conforming.  It was an
oversight during the development of the procedure pointer facility
that the EXTERNAL attribute was not removed from C512, that
"procedure pointer" was not added to C521, that C535 and C536
contradict one another, and that an external statement and specifying
the EXTERNAL attribute in a type declaration statement were not
allowed in C568.  It is not helpful that the last sentence of the
first paragraph of subclause 5.2 refers to "PROCEDURE ... statements"
(which could be confused with the PROCEDURE statement in an interface
block) where it should refer to "procedure declaration ...
statements."

EDITS:

Delete ", EXTERNAL" from C512 [72:28].

Insert ", a procedure pointer" after "dummy procedure" in C521 [73:7].

Replace C536 [73:35-36]:

"C536 (R501) If the PROTECTED attribute is specified, the INTRINSIC or
      PARAMETER attribute shall not be specified.  If the PROTECTED
      and EXTERNAL attributes are specified, the POINTER attribute
      shall also be specified."

Replace the last sentence of the first paragraph of subclause 5.2
[86:1] by "This also applies to procedure declaration statements, and
to EXTERNAL and INTRINSIC statements."

Replace C568 [91:5]:

"C568 (R541) The EXTERNAL attribute (5.1.2.6) shall be explicitly
      specified for a <proc-entity-name>."

SUBMITTED BY:  Van Snyder

HISTORY: 04-358    m169  F03/0012 Submitted
         04-358r2  m169  Revised
         04-418r1  m170  Failed J3 letter ballot #9
         04-401r2  m170  Passed by J3 meeting
         05-146    m171  Passed J3 letter ballot #10
         N1658     m176  Passed WG5 ballot N1657 - fix typo
         N1663           Reaffirmed in WG5 ballot N1661 on N1660

----------------------------------------------------------------------

NUMBER: F03/0020
TITLE: Kinds of intrinsic type parameters
KEYWORDS: type parameter, kind, intrinsic type
DEFECT TYPE: Erratum
STATUS: Passed by WG5 ballot

QUESTION:

Q1. What are the kinds of the type parameters for intrinsic types?

    In most contexts, it doesn't matter. Fortran 95 did not even
    have the concept of the kind of a type parameter or a context
    in which such a thing could be detected in a
    standard-conforming program.  Fortran 2003 added the concept
    in support of derived types. It also added a syntax which
    exposes the question for intrinsic types.

Q2. What is the KIND of a type parameter inquiry?

Q3. For example, consider the program

      program what_kind
        character c
        write (*,*) kind(c%kind) =3D=3D kind(0)
        write (*,*) kind(c%len) =3D=3D kind(0)
      end

    Are both write statements guaranteed to print .true. (meaning
    that the c%kind and c%len are of default kind) or not?

For KIND parameters, although I can't find it explicitly stated,
I see fairly strong evidence that all intrinsic kind parameters
are intended to be default integers.  This evidence is in the
intrinsic functions.  The KIND intrinsic function and all the
selected_*_kind functions are specified to return default
integers, which would make for some strangeness if the kind
parameters were not default integer, in particular if the KIND
intrinsic could not return the kind of its argument because that
kind could not be represented in a default integer.

There also seems no obvious benefit to having the kind of the
intrinsic kind parameters be anything other than default. In
practice, the number of supported values for kind is small and
would have no trouble being represented in a default integer;
large arrays of kind values are rare, so there isn't much
benefit in using representations smaller than default.

For character length, I see no similar evidence.  Indeed, the
LEN intrinsic seems to suggest that lengths might be other than
default integer. I believe that there was clear intent to
facilitate (but not require) support for character lengths
longer than could be expressed by a default integer.

In most contexts, it doesn't directly matter what the kind of
length is.  Parameter specifications in type-specs don't have to
match in kind. So the user could specify and do arithmetic on
lengths using whatever kind was appropriate for the anticipated
problem sizes. The limit on maximum character length is
processor-dependent anyway and is not necessarily the same
as HUGE(whatever) (though it is a bit hard to imagine how it
could usefully be larger).

The only context in which I can see that might matter is in a
type parameter inquiry (6.1.3).  We don't appear to have defined
the kind of a type parameter inquiry.  Although we didn't say, I
am assuming that a type parameter inquiry ought to "return" the
kind of the type parameter it is inquiring about. Otherwise,
there would be no way to inquire about the type parameter values
of some derived type variables (if the values didn't fit in a
default integer).  We probably ought to explicitly say, though.

ANSWER:

Q1. The kind parameters of all the intrinsic types are of
    default integer kind. The kind parameter of the intrinsic
    character length parameter is processor-dependent.

    The support for this answer is as described in the question.
    Edits are provided to make this answer explicit.

Q2. The kind parameter of a type inquiry is the same as that of
    the type parameter inquired about. See page 123, lines 35-36.

Q3. The first write statement is guaranteed to print a .true. value;
    it is processor dependent whether the second one prints a .true.
    or .false. value.

EDITS:

All edits apply to 04-007.

At [36:14], [37:30], [39:15], [40:14], and [44:2], insert the
following sentence before "The kind":
    The kind type parameter is of type default integer.

At [40:10], before "its", insert "its kind is processor-dependent
and".

SUBMITTED BY: Richard Maine

HISTORY: 04-408    m170  F03/0020 Submitted
         04-408r1  m170  Passed by J3 meeting
         05-146    m171  Passed J3 letter ballot #10
         N1658     m176  Passed WG5 ballot N1657
         N1663           Reaffirmed in WG5 ballot N1661 on N1660

----------------------------------------------------------------------

NUMBER: F03/0023
TITLE: IEEE_SET/GET_UNDERFLOW_MODE
KEYWORDS: IEEE, underflow mode
DEFECT TYPE: Erratum
STATUS: Passed by WG5 ballot

QUESTION:

Is it allowed for the argument of IEEE_SET_UNDERFLOW_MODE or
IEEE_GET_UNDERFLOW_MODE to be an array?

There appears to be no restriction against arrays in these
procedures.  For IEEE_SET_UNDERFLOW_MODE, it is ill-defined
what an array would mean.  The wording implies a scalar, in
that it talks about being true or false, but the restriction
to scalars is not explicit. For IEEE_GET_UNDERFLOW_MODE, it
could be defined, but seems a little silly and nonparallel.

The similar procedures for rounding mode do explicitly
specify that their arguments are scalar.

ANSWER:

No, arrays are not allowed for these arguments.  Edits are provided
to correct this error.

EDITS:

[374:21] Add "scalar and" after "shall be"
[380:13] Add "scalar and" after "shall be"

SUBMITTED BY: Richard Maine

HISTORY: 04-420    m170  F03/0023 Submitted - Passed by J3 meeting
         05-146    m171  Passed J3 letter ballot #10
         N1658     m176  Passed WG5 ballot N1657
         N1663           Reaffirmed in WG5 ballot N1661 on N1660

----------------------------------------------------------------------

NUMBER: F03/0025
TITLE: Abstract types in CLASS IS type guard statements
KEYWORDS: ABSTRACT, CLASS IS, type guard, SELECT TYPE
DEFECT TYPE: Erratum
STATUS: Passed by WG5 ballot

QUESTION:

Consider the following program:

      PROGRAM foo

        TYPE, ABSTRACT :: base
          INTEGER i
        END TYPE
        TYPE, EXTENDS(base) :: child
          INTEGER j
        END TYPE
        CLASS(*), POINTER :: x
        TYPE(child), TARGET :: c1

        x =3D> c1
        SELECT TYPE (x)
          CLASS IS (base)
            PRINT *, 'Class is base'
          CLASS DEFAULT
            PRINT *, 'Class is not base'
        END SELECT

      END

Constraint C401 seems to prohibit the abstract type "base" from
appearing in a CLASS IS type guard statement, thus prohibiting this
program.  There seems to be no reason to prohibit this, and allowing
it seems to be useful in some situations.

Was this program intended to be standard-conforming?

ANSWER:

Yes, this program was intended to be standard-conforming.  Edits are
provided to correct this oversight.

EDITS:

All edits refer to 04-007.
[162:17] Change "<type-spec>" to "<derived-type-spec>".
[162:19] After "<type-spec>", insert "or <derived-type-spec>".
[162:20] After "<type-spec>", insert "or <derived-type-spec>".
[162:21] After "<type-spec>", insert "or <derived-type-spec>".

SUBMITTED BY: Rob James

HISTORY: 04-411    m170  F03/0025 Submitted
         04-411r1  m170  Passed by J3 meeting
         05-146    m171  Passed J3 letter ballot #10
         N1658     m176  Passed WG5 ballot N1657
         N1663           Reaffirmed in WG5 ballot N1661 on N1660

----------------------------------------------------------------------

NUMBER: F03/0026
TITLE: Intrinsic types in CLASS IS type guard statements
KEYWORDS: CLASS IS, type guard, SELECT TYPE, intrinsic type
DEFECT TYPE: Erratum
STATUS: Passed by WG5 ballot

QUESTION:

Consider the following program:

      PROGRAM foo

        CLASS(*), POINTER :: x
        INTEGER, TARGET :: i

        x =3D> i
        SELECT TYPE (x)
          CLASS IS (INTEGER)
            PRINT *, 'How can INTEGER be a class?'
        END SELECT

      END

The description of a CLASS IS type guard statement refers to an
extension of the type specified.  This makes no sense for
nonextensible types.  C815 disallows all nonextensible derived types,
but nothing disallows intrinsic types, which are also nonextensible.

Was this program intended to be standard-conforming?

ANSWER:

No, this program was not intended to be standard-conforming.  Edits
are supplied to correct this oversight.

EDITS:

All edits refer to 04-007.  Note that these edits are the same as the
edits proposed for F03/0025.

[162:17] Change "<type-spec>" to "<derived-type-spec>".
[162:19] After "<type-spec>", insert "or <derived-type-spec>".
[162:20] After "<type-spec>", insert "or <derived-type-spec>".
[162:21] After "<type-spec>", insert "or <derived-type-spec>".

SUBMITTED BY: Rob James

HISTORY: 04-412    m170  F03/0026 Submitted
         04-412r1  m170  Passed by J3 meeting
         05-146    m171  Passed J3 letter ballot #10
         N1658     m176  Passed WG5 ballot N1657
         N1663           Reaffirmed in WG5 ballot N1661 on N1660

----------------------------------------------------------------------

NUMBER: F03/0027
TITLE: Assumed character length in type guard statements
KEYWORDS: CHARACTER, assumed length, type guard, SELECT TYPE
DEFECT TYPE: Erratum
STATUS: Passed by WG5 ballot

QUESTION:

Consider the following program:

      PROGRAM foo
        CHARACTER, TARGET :: c
        CLASS(*), POINTER :: p

        p =3D> c
        SELECT TYPE (p)
          TYPE IS (CHARACTER(*))
            PRINT *, 'Character of length ', LEN(p)
        END SELECT
      END

Constraint C814 says that, in a type guard statement, the <type-spec>
shall specify that each length type parameter is assumed.

Constraint C416 does not list a type guard statement as a context in
which "*" can be used as a length type parameter for a character.

Was this program intended to be standard-conforming?


ANSWER:

Yes, this program was intended to be standard-conforming.  Edits are
supplied to correct this oversight.


EDITS:

All edits refer to 04-007.  These edits assume that the edits for
F03/0026 are passed.

[41:9]   Remove "or".
[41:9+]  Add a new list item:
         "(3.5) in the <type-spec> or <derived-type-spec> of a type
          guard statement (8.1.5),
         or"
[41:33+] Add a new list item:
         "(3.5) If used in the <type-spec> of a type guard statement,
          the associating entity assumes its length from the selector."


SUBMITTED BY: Rob James

HISTORY: 04-413    m170  F03/0027 Submitted
         04-413r1  m170  Passed by J3 meeting
         05-146    m171  Passed J3 letter ballot #10
         N1658     m176  Passed WG5 ballot N1657 - fix edits
         N1663           Reaffirmed in WG5 ballot N1661 on N1660 - fix
                          edits

----------------------------------------------------------------------

NUMBER: F03/0028
TITLE: Commas in complex namelist output
KEYWORDS: Namelist, complex formatting, comma, semicolon
DEFECT TYPE: Erratum
STATUS: Passed by WG5 ballot

QUESTION:

The 7th paragraph in 10.9.2 for list directed output says:

"Complex constants are enclosed in parentheses with a
separator between the real and imaginary parts, each
produced as defined above for real constants. The separator
is a comma if the decimal edit mode is POINT; it is a
semicolon if the decimal edit mode is COMMA."

There are similar words in most other places where complex
formatting is described.

The second paragraph of 10.10.1.3 Namelist group object list
items says:

"When the next effective item is of type complex, the input
form of the input value consists of a left parenthesis
followed by an ordered pair of numeric input fields
separated by a comma and followed by a right parenthesis. "

Other places correctly describe namelist complex output as
having a separator, either a comma or a semicolon, depending
on the decimal edit mode.

Should the namelist version be reworded to say "comma or
semicolon"?

ANSWER:

Yes.  Edits are supplied to correct this oversight.
In addition, a similar issue exists for list directed input of
undelimited character values and namelist output of character
values.

EDITS:

All edits refer to 04-007.

[240:13] Replace "comma" with "comma (if the decimal edit mode is
         POINT), semicolon (if the decimal edit mode is COMMA)".

[244:29] Replace "a comma" by "a comma (if the decimal edit mode
         is POINT) or a semicolon (if the decimal edit mode is
         COMMA),".
[244:30] Before "The first", add the following sentence:
           The separator is a comma if the decimal edit mode is
           POINT; it is a semicolon if the decimal edit mode is
           COMMA.
[244:32] Replace "comma" with "separator".
[244:33] Replace "comma" with "separator".

[245:4] After "comma," insert " semicolon,".

SUBMITTED BY: Dick Hendrickson

HISTORY: 04-409    m170  F03/0028 Submitted
         04-409r1  m170  Passed by J3 meeting
         05-146    m171  Failed interp letter ballot #10
         05-164    m171  Passed by J3 meeting
         05-170    m172  Failed J3 letter ballot #11
         05-257    m173  Passed by J3 meeting
         06-133    m175  Passed J3 letter ballot #12
         N1658     m176  Passed WG5 ballot N1657 - fix edits
         N1663           Reaffirmed in WG5 ballot N1661 on N1660

----------------------------------------------------------------------

NUMBER: F03/0029
TITLE: Negative zero and intrinsic functions
KEYWORDS: Negative zero, IEEE, intrinsic functions
DEFECT TYPE: Erratum
STATUS: Passed by WG5 ballot

QUESTION:

4.4.2 states
  "Processors that distinguish between positive and negative zeros
   shall treat them as equivalent ... as actual arguments to intrinsic
   procedures other than those for which it is explicitly specified
   that negative zero is distinguished"

Q1. Does this mean that TRANSFER(-0.0,42) is required to give the same
    answer as TRANSFER(+0.0,42)?  The definition of TRANSFER has no
    explicit mention of negative zero.

Q2. Does this mean that MERGE(+0.0,-0.0,flag) always returns +0.0?

Q3. Does this mean that SPREAD(-0.0,2) has the value [+0.0,+0.0]
    instead of [-0.0,-0.0]?

Q4. Does this mean that RESHAPE([-0.0],[1]) has the value [+0.0]
    instead of [-0.0]?

Q5. Does this mean that SET_EXPONENT(-0.0,10) is +0.0 not -0.0?

Q6. Does this mean that if a REAL variable X has a negative zero
    value, REAL(x,...) has a positive zero value?

Q7. Does this mean that CMPLX(0,-0.0) has the value (+0.0,+0.0)
    instead of (+0.0,-0.0)?

Q8. Does this mean that if a complex variable C has a negative zero
    imaginary part, that AIMAG(C) returns +0.0 instead of -0.0?

Q9. In any other intrinsic function, if the definition of the
    intrinsic would imply a different result for negative zero than
    for positive zero, does this mean that the function returns the
    positive zero answer for a negative zero argument?

ANSWER:

Q1.  No.  The definition of TRANSFER explicitly states that its result
     has the same physical representation as its first argument.  This
     would not be possible if "equivalent" meant that the exact same
     result had to be produced.

Q2.  No, this would contradict the definition of MERGE.

Q3.  No.  SPREAD "replicates" its argument, which means that the value
     of each copy is the same as the original, not just compare equal.
     As with TRANSFER, this would not be possible with the suggested
     interpretation of the text in 4.4.2.

Q4+.  No.  As with the previous questions, this would require an
      overly strict interpretation of the term "equivalent",
      contradicting the clear intent of the function in question.

DISCUSSION:

The term "equivalent" in the quoted text in 4.4.2 refers to the
concept of mathematical equivalence, not physical or computational
equivalence.  A clarifying edit is supplied.

EDITS:

[38:2] Before "equivalent" insert "mathematically".

SUBMITTED BY: Malcolm Cohen

HISTORY: 04-422    m170  F03/0029 Submitted - Passed by J3 meeting
         05-146    m171  Passed J3 letter ballot #10
         N1658     m176  Passed WG5 ballot N1657
         N1663           Reaffirmed in WG5 ballot N1661 on N1660

----------------------------------------------------------------------

NUMBER: F03/0045
TITLE: Finalization and assumed-size arguments with INTENT(OUT)
KEYWORDS: finalization, INTENT(OUT), assumed size, dummy argument
DEFECT TYPE: Erratum
STATUS: Passed by WG5 ballot

QUESTION:

Consider the following program:

MODULE m
  TYPE t
    INTEGER :: i
  CONTAINS
    FINAL :: finalizeT
  END TYPE
CONTAINS
  ELEMENTAL SUBROUTINE finalizeT(f)
    TYPE(t), INTENT(INOUT) :: f
    f%i =3D 10
  END SUBROUTINE
END MODULE

SUBROUTINE xyz (d)
  USE m
  TYPE(t), INTENT(OUT) :: d(*)
END SUBROUTINE

PROGRAM foo
  USE m
  EXTERNAL xyz
  TYPE(t) :: a(10) =3D t(5)
  CALL xyz(a(2))
END PROGRAM

4.5.5.2 of Fortran 2003 states:
    When a procedure is invoked, a nonpointer, nonallocatable object
    that is an actual argument associated with an INTENT(OUT) dummy
    argument is finalized.

For assumed-size arguments, this situation is similar to that of
default initialization with INTENT(OUT).  Default initialization is
prohibited for INTENT(OUT), assumed-size dummy arguments by C544.  A
similar restriction on finalization may have been overlooked.

Was this program intended to be standard-conforming?

ANSWER:

No, this program was not intended to be standard-conforming.  An edit
is supplied to correct this oversight.

DISCUSSION:

The unstated philosophy of assumed-size arrays in the standard is that
no action is allowed on an assumed-size array which would need to be
applied elementally to the whole array.  That is why no whole array
assignment is allowed, for example.

In accordance with this philosophy,
(1) types with ultimate allocatable components also need to be
    excluded from being INTENT(OUT) assumed-size, as procedure
    invocation in this case requires deallocation of all the
    allocated components.

(2) polymorphic INTENT(OUT) assumed-size arrays should also be
    excluded, as they might have finalisation, default initialisation
    or allocatable components.

This interp subsumes Fortran 2003 interp #0060.

EDITS:

All edits refer to 04-007.

[80:9]  Before "of a type", insert
        "polymorphic, of a finalizable type, of a type with an
         ultimate allocatable component, or".

SUBMITTED BY: Rob James

HISTORY: 05-136    m171  F03/0045 Submitted, passed by J3 meeting
         05-170    m172  Passed J3 letter ballot #11
         N1622     m172  Failed WG5 ballot N1629
         05-256    m173  Passed by J3 meeting
         06-133    m175  Passed J3 letter ballot #12
         N1658     m176  Passed WG5 ballot N1657
         N1663           Reaffirmed in WG5 ballot N1661 on N1660

----------------------------------------------------------------------

NUMBER: F03/0056
TITLE: Null input values and list-directed UDDTIO
KEYWORDS: null value, UDDTIO
DEFECT TYPE: Interpretation
STATUS: Passed by WG5 ballot

QUESTION:

Consider the following program:

      MODULE m
        PRIVATE
        TYPE, PUBLIC :: t
          INTEGER i
          INTEGER j
        CONTAINS
          PROCEDURE, PRIVATE :: readFormatted =3D> readFormattedT
          GENERIC :: READ(FORMATTED) =3D> readFormatted
        END TYPE
      CONTAINS
        SUBROUTINE readformattedT(dtv, unit, iotype, v_list, iostat, =
iomsg)
          CLASS(t),     INTENT(INOUT) :: dtv
          INTEGER,      INTENT(IN)    :: unit
          CHARACTER(*), INTENT(IN)    :: iotype
          INTEGER,      INTENT(IN)    :: v_list(:)
          INTEGER,      INTENT(OUT)   :: iostat
          CHARACTER(*), INTENT(INOUT) :: iomsg
          READ (unit, *) dtv%i
          READ (unit, *) dtv%j
        END SUBROUTINE
      END MODULE

      PROGRAM p
        USE m
        INTEGER i
        TYPE(t) x, y, z
        x%i =3D 10
        x%j =3D 15
        y%i =3D 20
        y%j =3D 25
        z%i =3D 30
        z%j =3D 35
        i =3D 100
        READ (*,*) x, y, z, i
        PRINT *, x, y, z, i
      END PROGRAM

The following is given as input to this program:

1044 2167 3977 /
1 2 3


10.9.1.1 of Fortran 2003 (Null values) states:

    A slash encountered as a value separator during execution of a
    list-directed input statement causes termination of execution of
    that input statement after the assignment of the previous value.

If a child data transfer statement encounters a slash as a value
separator, it is unclear whether this statement applies to just the
child statement, or to the parent data transfer statement as well.
The significance for any subsequent child statement is also unclear.

What is the behaviour of this program when it is given the specified
input?


ANSWER:

When a child data transfer statement encounters a slash as a value
separator, only that data transfer statement encounters the slash.
None of its parent data transfer statements encounters the slash.
Only the data transfer statement that encounters the slash is
terminated.

The program above should print the following:
 1044.2167.3977.25.1.2.3
where "." represents a value separator.


EDITS:

None.


SUBMITTED BY: Rob James

HISTORY: 05-171    m172  F03/0056 Submitted
         05-218    m173  Passed by J3 meeting
         06-133    m175  Passed J3 letter ballot #12
         N1658     m176  Passed WG5 ballot N1657
         N1663           Reaffirmed in WG5 ballot N1661 on N1660

----------------------------------------------------------------------

NUMBER: F03/0057
TITLE: Namelist I/O and UDDTIO
KEYWORDS: namelist, UDDTIO
DEFECT TYPE: Erratum
STATUS: Passed by WG5 ballot

QUESTION:

Can namelist I/O ever invoke a user-defined derived-type I/O
procedure?

10.10.1.2 of Fortran 2003 (Namelist input values) implies that
namelist input cannot invoke a user-defined derived-type I/O
procedure.  It says that, for a derived-type variable, "the effect is
as if the variable represented were expanded into a sequence of scalar
list items of intrinsic data types", which would preclude any
derived-type I/O.

However, the same sentence says that this is done "in the same way
that formatted input/output list items are expanded (9.5.2)", which
would result in some effective list items of derived type.

9.5.3.6 and 9.5.3.7.2 also imply that a user-defined derived-type I/O
procedure could be invoked for a namelist group object.


ANSWER:

Yes, namelist I/O can invoke a user-defined derived-type I/O
procedure.  Edits are provided to correct this problem.


EDITS:

All edits refer to 04-007.

[244:8]   Remove "of intrinsic data types".

[244:10]  Remove "intrinsic".


SUBMITTED BY: Rob James

HISTORY: 05-172    m172  F03/0057 Submitted
         05-219    m173  Passed by J3 meeting
         06-133    m175  Passed J3 letter ballot #12
         N1658     m176  Passed WG5 ballot N1657
         N1663           Reaffirmed in WG5 ballot N1661 on N1660

----------------------------------------------------------------------

NUMBER: F03/0058
TITLE: Recursive namelist output
KEYWORDS: UDDTIO, namelist, output
DEFECT TYPE: Interpretation
STATUS: Passed by WG5 ballot

QUESTION:

Consider the following program:

      MODULE mod
        PRIVATE
        TYPE, PUBLIC :: node
          INTEGER :: value =3D 0
        CONTAINS
          PROCEDURE, PRIVATE :: nodeFormattedWrite =3D> writeroutine
          GENERIC :: WRITE(FORMATTED) =3D> nodeFormattedWrite
        END TYPE
      CONTAINS
        SUBROUTINE writeroutine(dtv, unit, iotype, vlist, iostat, =
iomsg)
          CLASS(node), INTENT(IN) :: dtv
          INTEGER, INTENT(IN) :: unit
          CHARACTER(LEN=3D*), INTENT(IN) :: iotype
          INTEGER, INTENT(IN) :: vlist(:)
          INTEGER, INTENT(OUT) :: iostat
          CHARACTER(LEN=3D*), INTENT(INOUT) :: iomsg

          REAL a
          NAMELIST /inner/ a
          a =3D 4.0
          WRITE(unit, NML=3Dinner)
        END SUBROUTINE
      END MODULE

      PROGRAM foo
        USE mod
        TYPE(node) :: a(2)
        NAMELIST /outer/ a
        a(1)%value =3D 1
        a(2)%value =3D 2
        WRITE(*, NML=3Douter)
      END PROGRAM

Is the following output standard-conforming for the above program?  If
not, please give an example of standard-conforming output.

 &OUTER
 A=3D &INNER
 A=3D4.000000000
 /,  &INNER
 A=3D4.000000000
 /
 /

ANSWER:

Yes

EDITS:

None

SUBMITTED BY: Rob James

HISTORY: 05-173    m172  F03/0058 Submitted
         05-220    m173  Passed by J3 meeting
         06-133    m175  Passed J3 letter ballot #12
         N1658     m176  Passed WG5 ballot N1657
         N1663           Reaffirmed in WG5 ballot N1661 on N1660

----------------------------------------------------------------------

NUMBER: F03/0060
TITLE: Default initialization of INTENT(OUT), assumed-size arrays
KEYWORDS: default initialization, INTENT(OUT), assumed size, =
polymorphism
DEFECT TYPE: Erratum
STATUS: Passed by WG5 ballot

QUESTION:

Consider the following program:

      MODULE m
        TYPE base
          INTEGER I
        END TYPE
        TYPE, EXTENDS(base) :: child
          INTEGER :: j =3D 5
        END TYPE
      CONTAINS
        SUBROUTINE sub(b)
          CLASS(base), INTENT(OUT) :: b(*)
        END SUBROUTINE
      END MODULE

      PROGRAM foo
        USE m
        TYPE(child) :: c(3)
        c%i =3D 12
        c%j =3D 47
        CALL sub(c)
        PRINT *, c%j
      END PROGRAM

C544 prevents nonpolymorphic, INTENT(OUT), assumed-size arrays from
having default initialization.  The polymorphic case, however, is not
checkable at compile time, so it cannot be a constraint.

Was it intended that the dynamic type of an INTENT(OUT), assumed-size
array could have default initialization?  If so, what does the above
program print?

ANSWER:

No, this was not intended.

This interp is subsumed by Fortran 2003 interp # 45,
which contains edits making the above example non-conforming.

EDITS:

None

SUBMITTED BY: Rob James

HISTORY: 05-175    m172  F03/0060 Submitted
         05-222    m173  Edit provided
         05-222r1  m173  Subsumed by 0045 - Passed  by J3 meeting
         06-133    m175  Passed J3 letter ballot #12
         N1658     m176  Passed WG5 ballot N1657
         N1663           Reaffirmed in WG5 ballot N1661 on N1660

----------------------------------------------------------------------

NUMBER: F03/0061
TITLE: Polymorphism and explicit-shape or assumed-size dummy arguments
KEYWORDS: polymorphism, assumed size, actual argument, dummy argument
DEFECT TYPE: Erratum
STATUS: Passed by WG5 ballot

QUESTION:

Consider the following program:

      MODULE m
        TYPE t1
          INTEGER :: i
        END TYPE
      CONTAINS
        SUBROUTINE abc (b)
          CLASS(t1) :: b(*)
          EXTERNAL xyz
          CALL xyz(b(2))
        END SUBROUTINE
      END MODULE

      SUBROUTINE xyz(d)
        USE m
        TYPE(t1) :: d(2,3)
      END SUBROUTINE

      PROGRAM foo
        USE m
        TYPE, EXTENDS(t1) :: t2
          INTEGER :: j
        END TYPE
        TYPE(t2) a(10)
        CALL abc(a(2))
      END PROGRAM

During the execution of "xyz", the dummy argument "d" is sequence
associated with the associated actual argument (which is true if "d"
has either explicit shape or assumed size).  This implies that the
entity that is argument associated with "d" must be contiguous.

The dummy argument "b" of the module subroutine "abc" is polymorphic,
and its dynamic type in this case is different than its declared type.
In this scoping unit, "xyz" has an implicit interface, so we know it
doesn't have any polymorphic arguments.  So, the dummy argument of
"xyz" must be nonpolymorphic, and have the same declared type as the
actual argument (b(2)).

This implies that we only want to pass the parent portion of b(2).
But the dummy argument of "xyz" may be an explicit-shape or
assumed-size array (in this case, it is an explicit-shape array).

This means that we have to pass a contiguous array to "xyz".  This
wouldn't be a problem if the dynamic type of "b" was the same as the
declared type, but in this case it is not.  The parent portion of "b"
(from element 2 to the end of the array) must be copied into a
temporary array.

The compiler cannot possibly know how big "b" is because it is an
assumed-size array, so it is impossible to make such a copy.

Was this program intended to be standard-conforming?

ANSWER:

No, this program was not intended to be standard-conforming.  Edits
are provided to correct this oversight.

EDITS:

All edits refer to 04-007.

[270:27]  Change "assumed-shape or pointer" to "assumed-shape,
          pointer, or polymorphic".

SUBMITTED BY: Rob James

HISTORY: 05-176    m172  F03/0061 Submitted
         05-223    m173  Passed by J3 meeting
         06-133    m175  Passed J3 letter ballot #12
         N1658     m176  Passed WG5 ballot N1657
         N1663           Reaffirmed in WG5 ballot N1661 on N1660

----------------------------------------------------------------------

NUMBER: F03/0062
TITLE: Finalization of array constructors
KEYWORDS: Finalization, array constructor
DEFECT TYPE: Erratum
STATUS: Passed by WG5 ballot

QUESTION:

Consider the following program:

      MODULE m
        TYPE t
          INTEGER i
        CONTAINS
          FINAL :: finalizeT
        END TYPE
      CONTAINS
        SUBROUTINE finalizeT(obj)
          TYPE(t) :: obj(:)
          PRINT *, 'Finalizing a rank-1 array of type t'
        END SUBROUTINE
      END MODULE

      PROGRAM foo
        USE m
        TYPE(t) :: a
        a%i =3D 5
        PRINT *, (/ (a, i=3D1,5) /)
      END PROGRAM

If the PRINT statement in the main program was printing a function
result or a structure constructor, rather than an array constructor,
it is clear that the object should be finalized after that PRINT
statement.

However, for array constructors, this does not appear to be the case.
In the main program above, should the entity created by the array
constructor be finalized after execution of the PRINT statement?

ANSWER:

Yes, the array constructor should be finalized.  Edits are provided to
correct this oversight.

EDITS:

This edit refers to 04-007.

[59:27]  After the first occurrence of "structure constructor", insert
         "or array constructor".  On the same line, delete the second
         occurrence of "structure".

This edit refers to the edit introduced by interpretation F03/0007.

         After the first occurrence of "structure constructor", insert
         "or array constructor". In the same sentence, delete the =
second
         occurrence of "structure".

SUBMITTED BY: Rob James

HISTORY: 05-177    m172  F03/0062 Submitted
         05-224    m173  Passed by J3 meeting
         06-133    m175  Passed J3 letter ballot #12
         N1658     m176  Passed WG5 ballot N1657 - fix edits
         N1663           Reaffirmed in WG5 ballot N1661 on N1660

----------------------------------------------------------------------

NUMBER: F03/0066
TITLE: Precision of operation
KEYWORDS: precision, operation
DEFECT TYPE: Interpretation
STATUS: Passed by WG5 ballot

QUESTION:

Given
  REAL X
  X =3D ... some value ...
  IF( (X+3.0) .EQ. 3.0 )... =20
may the X+3.0 be computed with more range and/or precision than that
of REAL?  In other words, is PRECISION(X) .EQ. PRECISION(X+3.0) always
true; or is PRECISION(X) .LT. PRECISION(X+3.0) sometimes true?

References are to J3/04-007.

2.4.1.1 Intrinsic type has "The kind type parameter indicates ... the
decimal precision and exponent range for the real and complex types,
..."

7.1.4.2 Type, type parameters, and shape of the result of an operation
has in (4) "For an expression x1 op x2 where op is a numeric intrinsic
binary operator with both operands of the same type and kind type
parameters, ..., the kind type parameter of the expression is
identical to that of each operand."

Since X and 3.0 are the same type and have the same kind type
parameters, 7.1.4.2 (4) appears to require the X+3.0 have just the
range and precision of REAL; no more, no less (otherwise, the
precision is not identical).  But, several members of the J3 email
list have said that the "+" may be done with more precision; using
either 1.4(6) or 7.1.8.3 as the reason.

Perhaps something alone the lines of "The values of floating operands
and of the results of floating expressions may be represented in
greater precision and range than that required by the kind type
parameter; the kind type parameter is not changed thereby." should be
added to 7.1.4.2(4).

QUESTION:

Is PRECISION(X) .EQ. PRECISION(X+3.0) always true?=20

ANSWER:

Yes, that is the definition of PRECISION.  The PRECISION intrinsic has
nothing to do with the precision in which the computation X+3.0 is
computed.  7.1.4.2 (4) only describes the precision of the end result
of the computation.

The weasel words in 1.4 (6) allow the processor to compute this =
expression
in higher precision than REAL.

EDITS:

None

SUBMITTED BY: Fred Tydeman

HISTORY: 05-193    m173  F03/0066 Submitted
         05-193r1  m173  Passed by J3 meeting
         06-133    m175  Passed J3 letter ballot #12
         N1658     m176  Passed WG5 ballot N1657
         N1663           Reaffirmed in WG5 ballot N1661 on N1660

----------------------------------------------------------------------

NUMBER: F03/0067
TITLE: Accuracy of conversion of real literal constants
KEYWORDS: conversion, accuracy
DEFECT TYPE: Interpretation
STATUS: Passed by WG5 ballot

QUESTION:

The following is independent of IEEE-754.

Fortran 2003 10.6.1.2.6 covers conversions between "decimal values"
and "internal values" and has some strong requirements.

Are there equivalent requirements on accuracy for conversions of real
literal constants?  Sections 4.1.2 and 4.4.2 seems like the places to
find them (if they exist).

What rounding mode is used for conversions of real literal constants?
Is the same rounding mode used for all such conversions?

The following four questions are about positive values, but the same
would apply to negative values.

Must all "decimal values" in the range smallest non-zero finite
internal value (which could be a denormal) to largest finite internal
value, e.g. 0.1, be converted?

Must all "decimal values" in the range zero to smallest non-zero
finite internal value, e.g. 1.0e-999999999, be converted?

Must all "decimal values" larger than the largest finite internal
value, e.g. 9.9e+99999999999, be converted if infinity is an internal
value?  What does nearest rounding mean for these cases?

What requirements exist for "decimal values" larger than the largest
finite internal value if infinity is not an internal value?

ANSWER:

There are no requirements on accuracy for conversions of real literal
constants.

The standard does not specify the rounding mode used for conversions
of real literal constants, nor does it require the same rounding mode
to be used for all conversions.

Whether all decimal values in any range can be converted is not
standardized.

There are no requirements for "decimal values" larger than the largest
finite internal value whether infinity is an internal value or not.

EDITS:

None

SUBMITTED BY: Fred Tydeman

HISTORY: 05-206    m173  F03/0067 Submitted
	 05-206r1  m173  Passed by J3 meeting
         06-133    m175  Passed J3 letter ballot #12
         N1658     m176  Passed WG5 ballot N1657
         N1663           Reaffirmed in WG5 ballot N1661 on N1660

----------------------------------------------------------------------

NUMBER: F03/0068
TITLE: First character of namelist output records
KEYWORDS: namelist, output, UDDTIO
DEFECT TYPE: Erratum
STATUS: Passed by WG5 ballot

QUESTION:

The last sentence of 10.10.2.2 of Fortran 2003 states:
    Except for continuation of delimited character sequences, each
    output record begins with a blank character.

If a namelist output statement causes a user-defined derived-type
output procedure to be called, was it intended to be standard-
conforming for that procedure to create a new record (perhaps by using
the slash edit descriptor) that does not begin with a blank character?

ANSWER:

Yes, this situation was intended to be standard-conforming.  Explicit
formatting
in user-defined derived-type output is not required to output a leading
blank
in this case.  An edit is provided to correct this oversight.

EDITS:

All edits refer to 04-007.

[247:33] Before "continuation", insert "new records created by
         explicit formatting within a user-defined derived-type
         output procedure or by".

SUBMITTED BY: Rob James

HISTORY: 05-227    m173  F03/0068 Submitted
         05-227r1  m173  Passed by J3 meeting
         06-133    m175  Passed J3 letter ballot #12
         N1658     m176  Passed WG5 ballot N1657
         N1663           Reaffirmed in WG5 ballot N1661 on N1660
=20
----------------------------------------------------------------------

NUMBER: F03/0069
TITLE: Procedure pointers in defined assignment
KEYWORDS: procedure pointer, defined assignment
DEFECT TYPE: Erratum
STATUS: Passed by WG5 ballot

QUESTION:

In 12.3.2.1.1 of Fortran 2003, at [262:8-9], the following is stated
about the dummy arguments of a function that defines an operation:
    The dummy arguments shall be nonoptional dummy data objects and
    shall be specified with INTENT (IN).

This clearly states that a dummy argument of such a function cannot be
a procedure pointer.  The same is not stated for the dummy arguments
of a subroutine that defines assignment.

Was it intended that procedure pointers should be allowed in defined
assignment, but not in defined operations?

ANSWER:

No.  It was not intended that procedure pointers should be allowed in
either defined assignment or defined operations.  An edit is provided
to correct this oversight.

EDITS:

All edits refer to 04-007.

[263:6]  Replace "Each argument shall be nonoptional." with
         "The dummy arguments shall be nonoptional dummy data objects."

SUBMITTED BY: Rob James

HISTORY: 05-228    m173  F03/0069 Passed by J3 meeting
         06-133    m175  Passed J3 letter ballot #12
         N1658     m176  Passed WG5 ballot N1657
         N1663           Reaffirmed in WG5 ballot N1661 on N1660

----------------------------------------------------------------------

NUMBER: F03/0070
TITLE: Can child I/O statements be advancing I/O statements?
KEYWORDS: UDDTIO, ADVANCE=3D
DEFECT TYPE: Erratum
STATUS: Passed by WG5 ballot

[175:30-31] of Fortran 2003 states:
    An advancing input/output statement always positions a record file
    after the last record read or written, unless there is an error
    condition.

Since a child I/O statement does not position a file after the last
Record [194:19][199:8-9], this implies that a child I/O statement =
cannot=20
be an advancing I/O statement.

[189:6-9] of Fortran 2003 states:
    The ADVANCE=3D specifier determines whether advancing input/output
    occurs for this input/output statement. If YES is specified,
    advancing input/output occurs. If NO is specified, nonadvancing
    input/output occurs (9.2.3.1). If this specifier is omitted from
    an input/output statement that allows the specifier, the default
    value is YES.

This clearly states that any data transfer statement is an advancing
I/O statement if the value 'NO' is not specified for the ADVANCE=3D
specifier.

These two statements seem to contradict each other.=20

QUESTION:

If a child I/O statement does not have an ADVANCE=3D specifier with the
value 'NO', is it an advancing I/O statement?

DISCUSSION:

The answer to this question affects the value for the IOSTAT variable
for child READ statements in some situations.  For example, in the
following program, the value of "stat1" should be equal to IOSTAT_EOF
if the child READ statement is advancing, but it should be equal to
IOSTAT_EOR if the statement is nonadvancing.

      MODULE m
        TYPE t
          CHARACTER(2) :: x(2)
        CONTAINS
          PROCEDURE :: readT
          GENERIC :: READ(FORMATTED) =3D> readT
        END TYPE
      CONTAINS
        SUBROUTINE readT(dtv, unit, iotype, v_list, iostat, iomsg)
          CLASS(t), INTENT(INOUT) :: dtv
          INTEGER, INTENT(IN) :: unit
          CHARACTER(*), INTENT(IN) :: iotype
          INTEGER, INTENT(IN)  :: v_list(:)
          INTEGER, INTENT(OUT) :: iostat
          CHARACTER(*), INTENT(INOUT) :: iomsg
          READ (unit, '(2a2)', IOSTAT=3Diostat) dtv%x
        END SUBROUTINE
      END MODULE

      PROGRAM p
        USE m
        USE, INTRINSIC :: ISO_FORTRAN_ENV
        TYPE(t) t1
        CHARACTER(3) :: c =3D '123'
        INTEGER stat1
        READ (c, *, IOSTAT=3Dstat1) t1
        PRINT *, (stat1 =3D=3D IOSTAT_EOR), (stat1 =3D=3D IOSTAT_EOF)
      END PROGRAM

ANSWER:

No, such a child I/O statement is not advancing.  Edits are provided
to correct this inconsistency.

EDITS:

All edits refer to 04-007.

[189:7]  Replace "this input/output statement" by "a nonchild
         input/output statement".

[189:9]  Replace "from an input/output statement" by "from a
         nonchild input/output statement".

[189:9]  After "YES." Insert
         "  A formatted child input/output statement is a
           nonadvancing input/output statement, and any ADVANCE=3D
           specifier is ignored."

[199:8+] Add a new bullet:
         " o Any ADVANCE=3D specifier in a child input/output statement =
is
             ignored."

SUBMITTED BY: Rob James

HISTORY: 05-229    m173  F03/0070 Submitted
         05-229r1  m173  Passed by J3 meeting
         06-133    m175  Passed J3 letter ballot #12 - typos fixed
         N1658     m176  Passed WG5 ballot N1657 - fix edits
         N1663           Reaffirmed in WG5 ballot N1661 on N1660

----------------------------------------------------------------------

NUMBER: F03/0072
TITLE: Default initialization for "automatic" components
KEYWORDS: Parameterized Derived Type, Default Initialization
DEFECT TYPE: Erratum
STATUS: Passed by WG5 ballot

QUESTION:

Consider
  TYPE t(len)
    INTEGER,LEN :: len
    CHARACTER(len) :: cvalue =3D "xyz"
  END TYPE

  SUBROUTINE s(n)
    TYPE(t(n)) x
    ...

  TYPE t2(len2)
    TYPE(t(len2)) :: tvalue =3D t(10,"fred nurke")
  END TYPE

  SUBROUTINE s2(n)
    TYPE(t2(n)) :: y
    ...

The type definition for T appears to conform to the standard; it
allows an "automatic" component to be default initialized.  However,
the declaration of the local variable X in subroutine S will
initialize the component differently depending on the value of N, for
example, giving the CVALUE component the value "", "x", "xy", "xyz",
"xyz " for N being 0, 1, 2, 3, 4 respectively.

Q1. Was it intended that "automatic" components can be
    default-initialized?

If the answer is "Yes", the type definition for T2 also appears to
conform to the standard.  However, the declaration of Y in S2 will not
work if N has any value other than 10 at run time.  This is
surprising;  there appears to be no other situation where the runtime
value of a length type parameter can render a declaration invalid.

Q2. Is this situation intentional?

ANSWER:

Q1. No, this was not intended.  An edit is supplied to fix this.

Q2. Not applicable.

EDITS:

In 4.5.3 Components, immediately before R445
<proc-component-def-stmt>, insert a new constraint: [50:40+]
"C447a (R440) If <component-initialization> appears, every type
              parameter and array bound of the component shall be an
              initialization expression."

SUBMITTED BY: Malcolm Cohen

HISTORY: 05-285    m174  F03/0072 Submitted
	 05-285r1  m174  Revised edit
         06-133    m175  Passed J3 letter ballot #12
         N1658     m176  Passed WG5 ballot N1657
         N1663           Reaffirmed in WG5 ballot N1661 on N1660


Sally Seitz
Program Manager
American National Standards Institute
25 West 43rd Street, 4th Floor
New York, NY 10036
Tel: 212 642 4918
Fax: 212 840 2298


------_=_NextPart_001_01C6AA73.CC113FA2
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2658.24">
<TITLE>N 4082-Defect Report 2 for ISO/IEC 1539-1: 2004, Programming =
languages - Fortran</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>ISO/IEC JTC 1/SC22</FONT>
<BR><FONT SIZE=3D2>Programming languages, their environments and system =
software interfaces</FONT>
<BR><FONT SIZE=3D2>Secretariat:=A0 U.S.A.=A0 (ANSI) </FONT>
<BR><FONT SIZE=3D2>=A0 </FONT>
<BR><FONT SIZE=3D2>ISO/IEC JTC 1/SC22 N4082</FONT>
<BR><FONT SIZE=3D2>=A0 </FONT>
<BR><FONT SIZE=3D2>TITLE: </FONT>
<BR><FONT SIZE=3D2>Defect Report 2 for ISO/IEC 1539-1: 2004, =
Programming languages - Fortran</FONT>
</P>

<P><FONT SIZE=3D2>DATE ASSIGNED: </FONT>
<BR><FONT SIZE=3D2>2006-07-17</FONT>
<BR><FONT SIZE=3D2>=A0 </FONT>
<BR><FONT SIZE=3D2>SOURCE: </FONT>
<BR><FONT SIZE=3D2>SC 22/WG 5 Convener (J. Reid)</FONT>
</P>

<P><FONT SIZE=3D2>BACKWARD POINTER: </FONT>
<BR><FONT SIZE=3D2>N/A </FONT>
<BR><FONT SIZE=3D2>=A0 </FONT>
<BR><FONT SIZE=3D2>DOCUMENT TYPE: </FONT>
<BR><FONT SIZE=3D2>Defect Report</FONT>
<BR><FONT SIZE=3D2>=A0</FONT>
<BR><FONT SIZE=3D2>PROJECT NUMBER: </FONT>
</P>

<P><FONT SIZE=3D2>=A0 </FONT>
<BR><FONT SIZE=3D2>STATUS: </FONT>
<BR><FONT SIZE=3D2>For information and review when voting on N =
4080.</FONT>
</P>

<P><FONT SIZE=3D2>ACTION IDENTIFIER: </FONT>
<BR><FONT SIZE=3D2>FYI</FONT>
<BR><FONT SIZE=3D2>=A0 </FONT>
<BR><FONT SIZE=3D2>DUE DATE: </FONT>
<BR><FONT SIZE=3D2>=A0 </FONT>
<BR><FONT SIZE=3D2>DISTRIBUTION: </FONT>
<BR><FONT SIZE=3D2>TEXT</FONT>
</P>

<P><FONT SIZE=3D2>CROSS REFERENCE: </FONT>
<BR><FONT SIZE=3D2>=A0 </FONT>
<BR><FONT SIZE=3D2>DISTRIBUTION FORM: </FONT>
<BR><FONT SIZE=3D2>Def </FONT>
</P>

<P><FONT SIZE=3D2>_________end of cover sheet, beginning of =
document___________</FONT>
</P>

<P><FONT SIZE=3D2>ISO/IEC JTC1/SC22/WG5 N1666</FONT>
<BR><FONT SIZE=3D2>Defect Report 2 for Fortran 2003</FONT>
</P>

<P><FONT SIZE=3D2>All edits specified in this document relate to =
WG5-N1601 (j3/04-007).</FONT>
<BR><FONT SIZE=3D2>Other references to page and line numbers in general =
refer to the</FONT>
<BR><FONT SIZE=3D2>standard document as it was at the time of the =
initial interpretation</FONT>
<BR><FONT SIZE=3D2>request and/or subsequent interpretation =
work.</FONT>
</P>

<P><FONT =
SIZE=3D2>---------------------------------------------------------------=
-------</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>NUMBER: F03/0008</FONT>
<BR><FONT SIZE=3D2>TITLE: Pointer assignment and arrays</FONT>
<BR><FONT SIZE=3D2>KEYWORDS: pointer assignment, array, data-ref</FONT>
<BR><FONT SIZE=3D2>DEFECT TYPE: Erratum</FONT>
<BR><FONT SIZE=3D2>STATUS: Passed by WG5 ballot</FONT>
</P>

<P><FONT SIZE=3D2>QUESTION:</FONT>
</P>

<P><FONT SIZE=3D2>There appears to be no explicit requirement that =
the</FONT>
<BR><FONT SIZE=3D2>&lt;variable&gt;s in R736 and R741 be scalar.&nbsp; =
If data-pointer-object</FONT>
<BR><FONT SIZE=3D2>and proc-component ref were data-refs, then C614 =
would prohibit</FONT>
<BR><FONT SIZE=3D2>the &lt;variable&gt;s from being arrays.&nbsp; =
However, although the syntax</FONT>
<BR><FONT SIZE=3D2>looks like a special case of a data-ref, nothing =
appears to say</FONT>
<BR><FONT SIZE=3D2>that R736 and R741 actually constitute =
data-refs.</FONT>
</P>

<P><FONT SIZE=3D2>The standard gives no interpretation as to what the =
meaning</FONT>
<BR><FONT SIZE=3D2>would be in the case of an array.</FONT>
</P>

<P><FONT SIZE=3D2>Even when variable is a scalar, the standard does not =
appear to</FONT>
<BR><FONT SIZE=3D2>define what the properties (such as type and shape) =
of a</FONT>
<BR><FONT SIZE=3D2>data-pointer-object or proc-pointer-object are in =
the case where</FONT>
<BR><FONT SIZE=3D2>the syntax has a &quot;%&quot;.&nbsp; All we have is =
a syntax with no</FONT>
<BR><FONT SIZE=3D2>established meaning.</FONT>
</P>

<P><FONT SIZE=3D2>Q1. Is the &lt;variable&gt; in R736 or R741 allowed =
to be an array?</FONT>
</P>

<P><FONT SIZE=3D2>Q2. Is the interpretation of the forms in R736 and =
R741 the</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; same as that of a =
data-ref?</FONT>
</P>

<P><FONT SIZE=3D2>ANSWER:</FONT>
</P>

<P><FONT SIZE=3D2>A1. No.&nbsp; The standard provides no interpretation =
of what such</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; a form would mean.&nbsp; =
Therefore, by the first sentence of</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; 1.5, it is not =
standard-conforming.&nbsp; Edits are provided to</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; make this prohibition more =
direct.</FONT>
</P>

<P><FONT SIZE=3D2>A2. Yes.</FONT>
</P>

<P><FONT SIZE=3D2>EDITS:</FONT>
</P>

<P><FONT SIZE=3D2>All edits refer to 04-007.</FONT>
</P>

<P><FONT SIZE=3D2>[143:12,24,35,37] Insert &quot;&lt;scalar-&gt;&quot; =
before &quot;&lt;variable&gt;&quot;, four times.</FONT>
</P>

<P><FONT SIZE=3D2>SUBMITTED BY: Richard Maine</FONT>
</P>

<P><FONT SIZE=3D2>HISTORY: 04-333&nbsp;&nbsp;&nbsp; m169&nbsp; F03/0008 =
Submitted</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
04-333r1&nbsp; m169&nbsp; Passed by J3 meeting</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
04-418r1&nbsp; m170&nbsp; Failed J3 letter ballot #9</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
04-421&nbsp;&nbsp;&nbsp; m170&nbsp; Revised - Passed by J3 =
meeting</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
05-146&nbsp;&nbsp;&nbsp; m171&nbsp; Passed J3 letter ballot #10</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
N1658&nbsp;&nbsp;&nbsp;&nbsp; m176&nbsp; Passed WG5 ballot N1657</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
N1663&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Reaffirmed in WG5 ballot N1661 on N1660</FONT>
</P>

<P><FONT =
SIZE=3D2>---------------------------------------------------------------=
-------</FONT>
</P>

<P><FONT SIZE=3D2>NUMBER: F03/0012</FONT>
<BR><FONT SIZE=3D2>TITLE:&nbsp; Procedure pointers and the EXTERNAL =
attribute</FONT>
<BR><FONT SIZE=3D2>KEYWORDS: Procedure pointers, EXTERNAL</FONT>
<BR><FONT SIZE=3D2>DEFECT TYPE: Erratum</FONT>
<BR><FONT SIZE=3D2>STATUS: Passed by WG5 ballot</FONT>
</P>

<P><FONT SIZE=3D2>QUESTION:</FONT>
</P>

<P><FONT SIZE=3D2>Is the following program unit standard =
conforming?</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp; SUBROUTINE SUB ( RPP )</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; REAL, EXTERNAL, POINTER :: =
RPP</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; EXTERNAL :: PP</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; POINTER :: PP</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; PROCEDURE(REAL), POINTER :: PPP =
=3D&gt; NULL()</FONT>
<BR><FONT SIZE=3D2>&nbsp; END SUBROUTINE SUB</FONT>
</P>

<P><FONT SIZE=3D2>The last sentence of &quot;5.1.2.6 EXTERNAL =
attribute&quot; appears to indicate</FONT>
<BR><FONT SIZE=3D2>that it is allowed:</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp; &quot;A procedure that has both the EXTERNAL =
and POINTER attributes is a</FONT>
<BR><FONT SIZE=3D2>&nbsp; procedure pointer.&quot;</FONT>
</P>

<P><FONT SIZE=3D2>That the title of subclause 12.2.1.2 is =
&quot;Characteristics of dummy</FONT>
<BR><FONT SIZE=3D2>procedures and dummy procedure pointers&quot; =
suggests that it is allowed.</FONT>
<BR><FONT SIZE=3D2>That subclause continues &quot;... whether it is a =
pointer, ...&quot; so it was</FONT>
<BR><FONT SIZE=3D2>clearly envisioned that at least dummy procedures =
could have the</FONT>
<BR><FONT SIZE=3D2>POINTER attribute.</FONT>
</P>

<P><FONT SIZE=3D2>C1216 [264:30] appears to require PPP to be =
allowed:</FONT>
</P>

<P><FONT SIZE=3D2>&quot;C1216 (R1214) If =3D&gt; appears in =
&lt;proc-decl&gt;, the procedure entity</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; shall have the =
pointer attribute.&quot;</FONT>
</P>

<P><FONT SIZE=3D2>On the other hand, A conspiracy of C512 =
[72:28-29]</FONT>
</P>

<P><FONT SIZE=3D2>&quot;C512 (R501) If the POINTER attribute is =
specified, the ALLOCATABLE,</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; TARGET, EXTERNAL, or =
INTRINSIC attribute shall not be</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
specified.&quot;</FONT>
</P>

<P><FONT SIZE=3D2>the second sentence of subclause 5.1.2.6 =
[80:38-40]</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp; &quot;This [EXTERNAL] attribute may also be =
specified by ... a</FONT>
<BR><FONT SIZE=3D2>&nbsp; =
&lt;procedure-declaration-stmt&gt;...&quot;</FONT>
</P>

<P><FONT SIZE=3D2>the first paragraph of subclause 5.2 [85:15ff]</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp; &quot;The combination of attributes that may =
be specified for a</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; particular entity is subject to the =
same restrictions ...</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; regardless of the method of =
specification.&nbsp; This also applies to</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; the PROCEDURE, EXTERNAL and INTRINSIC =
statements.&quot;</FONT>
</P>

<P><FONT SIZE=3D2>and the last sentence of the first paragraph of =
12.3.2.3 [264:8]</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp; &quot;It [the procedure declaration statement] =
specifies the EXTERNAL</FONT>
<BR><FONT SIZE=3D2>&nbsp; attribute....&quot;</FONT>
</P>

<P><FONT SIZE=3D2>appears to completely wipe out procedure pointers =
(PPP because of the</FONT>
<BR><FONT SIZE=3D2>first paragraph of 12.3.2.3).</FONT>
</P>

<P><FONT SIZE=3D2>C521 [73:6-7] and C568 [91:5] also appear to prohibit =
RPP and PP:</FONT>
</P>

<P><FONT SIZE=3D2>&quot;C521 (R504) The &lt;function-name&gt; shall be =
the name of an external</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; function, a function =
dummy procedure{, or a statement</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
function}.&quot;</FONT>
</P>

<P><FONT SIZE=3D2>&quot;C568 (R541) A &lt;proc-entity-name&gt; shall =
also be declared in a</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&lt;procedure-declaration-stmt&gt;.&quot;</FONT>
</P>

<P><FONT SIZE=3D2>But then the first paragraph after R1210 (defining =
the EXTERNAL</FONT>
<BR><FONT SIZE=3D2>statement) [264:1] appears to allow RPP and =
PP:</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp; &quot;Each &lt;external-name&gt; shall be the =
name of ... a procedure</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; pointer....&quot;</FONT>
</P>

<P><FONT SIZE=3D2>There is also a problem with protected procedure =
pointers.&nbsp; C535</FONT>
<BR><FONT SIZE=3D2>clearly envisions their existence:</FONT>
</P>

<P><FONT SIZE=3D2>&quot;C535 (R501) The PROTECTED attribute is =
permitted only for a procedure</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
pointer....&quot;</FONT>
</P>

<P><FONT SIZE=3D2>while C536 prohibits their existence:</FONT>
</P>

<P><FONT SIZE=3D2>&quot;C536 (R501) If the PROTECTED attribute is =
specified, the EXTERNAL ...</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; attribute shall not =
be specified.&quot;</FONT>
</P>

<P><FONT SIZE=3D2>ANSWER:</FONT>
</P>

<P><FONT SIZE=3D2>The discussion of procedure pointers is indeed =
inconsistent.</FONT>
</P>

<P><FONT SIZE=3D2>The program unit is intended to be standard =
conforming.&nbsp; It was an</FONT>
<BR><FONT SIZE=3D2>oversight during the development of the procedure =
pointer facility</FONT>
<BR><FONT SIZE=3D2>that the EXTERNAL attribute was not removed from =
C512, that</FONT>
<BR><FONT SIZE=3D2>&quot;procedure pointer&quot; was not added to C521, =
that C535 and C536</FONT>
<BR><FONT SIZE=3D2>contradict one another, and that an external =
statement and specifying</FONT>
<BR><FONT SIZE=3D2>the EXTERNAL attribute in a type declaration =
statement were not</FONT>
<BR><FONT SIZE=3D2>allowed in C568.&nbsp; It is not helpful that the =
last sentence of the</FONT>
<BR><FONT SIZE=3D2>first paragraph of subclause 5.2 refers to =
&quot;PROCEDURE ... statements&quot;</FONT>
<BR><FONT SIZE=3D2>(which could be confused with the PROCEDURE =
statement in an interface</FONT>
<BR><FONT SIZE=3D2>block) where it should refer to &quot;procedure =
declaration ...</FONT>
<BR><FONT SIZE=3D2>statements.&quot;</FONT>
</P>

<P><FONT SIZE=3D2>EDITS:</FONT>
</P>

<P><FONT SIZE=3D2>Delete &quot;, EXTERNAL&quot; from C512 =
[72:28].</FONT>
</P>

<P><FONT SIZE=3D2>Insert &quot;, a procedure pointer&quot; after =
&quot;dummy procedure&quot; in C521 [73:7].</FONT>
</P>

<P><FONT SIZE=3D2>Replace C536 [73:35-36]:</FONT>
</P>

<P><FONT SIZE=3D2>&quot;C536 (R501) If the PROTECTED attribute is =
specified, the INTRINSIC or</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; PARAMETER attribute =
shall not be specified.&nbsp; If the PROTECTED</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; and EXTERNAL =
attributes are specified, the POINTER attribute</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; shall also be =
specified.&quot;</FONT>
</P>

<P><FONT SIZE=3D2>Replace the last sentence of the first paragraph of =
subclause 5.2</FONT>
<BR><FONT SIZE=3D2>[86:1] by &quot;This also applies to procedure =
declaration statements, and</FONT>
<BR><FONT SIZE=3D2>to EXTERNAL and INTRINSIC statements.&quot;</FONT>
</P>

<P><FONT SIZE=3D2>Replace C568 [91:5]:</FONT>
</P>

<P><FONT SIZE=3D2>&quot;C568 (R541) The EXTERNAL attribute (5.1.2.6) =
shall be explicitly</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; specified for a =
&lt;proc-entity-name&gt;.&quot;</FONT>
</P>

<P><FONT SIZE=3D2>SUBMITTED BY:&nbsp; Van Snyder</FONT>
</P>

<P><FONT SIZE=3D2>HISTORY: 04-358&nbsp;&nbsp;&nbsp; m169&nbsp; F03/0012 =
Submitted</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
04-358r2&nbsp; m169&nbsp; Revised</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
04-418r1&nbsp; m170&nbsp; Failed J3 letter ballot #9</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
04-401r2&nbsp; m170&nbsp; Passed by J3 meeting</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
05-146&nbsp;&nbsp;&nbsp; m171&nbsp; Passed J3 letter ballot #10</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
N1658&nbsp;&nbsp;&nbsp;&nbsp; m176&nbsp; Passed WG5 ballot N1657 - fix =
typo</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
N1663&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Reaffirmed in WG5 ballot N1661 on N1660</FONT>
</P>

<P><FONT =
SIZE=3D2>---------------------------------------------------------------=
-------</FONT>
</P>

<P><FONT SIZE=3D2>NUMBER: F03/0020</FONT>
<BR><FONT SIZE=3D2>TITLE: Kinds of intrinsic type parameters</FONT>
<BR><FONT SIZE=3D2>KEYWORDS: type parameter, kind, intrinsic =
type</FONT>
<BR><FONT SIZE=3D2>DEFECT TYPE: Erratum</FONT>
<BR><FONT SIZE=3D2>STATUS: Passed by WG5 ballot</FONT>
</P>

<P><FONT SIZE=3D2>QUESTION:</FONT>
</P>

<P><FONT SIZE=3D2>Q1. What are the kinds of the type parameters for =
intrinsic types?</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; In most contexts, it doesn't =
matter. Fortran 95 did not even</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; have the concept of the kind of a =
type parameter or a context</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; in which such a thing could be =
detected in a</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; standard-conforming =
program.&nbsp; Fortran 2003 added the concept</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; in support of derived types. It =
also added a syntax which</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; exposes the question for =
intrinsic types.</FONT>
</P>

<P><FONT SIZE=3D2>Q2. What is the KIND of a type parameter =
inquiry?</FONT>
</P>

<P><FONT SIZE=3D2>Q3. For example, consider the program</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; program =
what_kind</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; character =
c</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; write =
(*,*) kind(c%kind) =3D=3D kind(0)</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; write =
(*,*) kind(c%len) =3D=3D kind(0)</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; end</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; Are both write statements =
guaranteed to print .true. (meaning</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; that the c%kind and c%len are of =
default kind) or not?</FONT>
</P>

<P><FONT SIZE=3D2>For KIND parameters, although I can't find it =
explicitly stated,</FONT>
<BR><FONT SIZE=3D2>I see fairly strong evidence that all intrinsic kind =
parameters</FONT>
<BR><FONT SIZE=3D2>are intended to be default integers.&nbsp; This =
evidence is in the</FONT>
<BR><FONT SIZE=3D2>intrinsic functions.&nbsp; The KIND intrinsic =
function and all the</FONT>
<BR><FONT SIZE=3D2>selected_*_kind functions are specified to return =
default</FONT>
<BR><FONT SIZE=3D2>integers, which would make for some strangeness if =
the kind</FONT>
<BR><FONT SIZE=3D2>parameters were not default integer, in particular =
if the KIND</FONT>
<BR><FONT SIZE=3D2>intrinsic could not return the kind of its argument =
because that</FONT>
<BR><FONT SIZE=3D2>kind could not be represented in a default =
integer.</FONT>
</P>

<P><FONT SIZE=3D2>There also seems no obvious benefit to having the =
kind of the</FONT>
<BR><FONT SIZE=3D2>intrinsic kind parameters be anything other than =
default. In</FONT>
<BR><FONT SIZE=3D2>practice, the number of supported values for kind is =
small and</FONT>
<BR><FONT SIZE=3D2>would have no trouble being represented in a default =
integer;</FONT>
<BR><FONT SIZE=3D2>large arrays of kind values are rare, so there isn't =
much</FONT>
<BR><FONT SIZE=3D2>benefit in using representations smaller than =
default.</FONT>
</P>

<P><FONT SIZE=3D2>For character length, I see no similar =
evidence.&nbsp; Indeed, the</FONT>
<BR><FONT SIZE=3D2>LEN intrinsic seems to suggest that lengths might be =
other than</FONT>
<BR><FONT SIZE=3D2>default integer. I believe that there was clear =
intent to</FONT>
<BR><FONT SIZE=3D2>facilitate (but not require) support for character =
lengths</FONT>
<BR><FONT SIZE=3D2>longer than could be expressed by a default =
integer.</FONT>
</P>

<P><FONT SIZE=3D2>In most contexts, it doesn't directly matter what the =
kind of</FONT>
<BR><FONT SIZE=3D2>length is.&nbsp; Parameter specifications in =
type-specs don't have to</FONT>
<BR><FONT SIZE=3D2>match in kind. So the user could specify and do =
arithmetic on</FONT>
<BR><FONT SIZE=3D2>lengths using whatever kind was appropriate for the =
anticipated</FONT>
<BR><FONT SIZE=3D2>problem sizes. The limit on maximum character length =
is</FONT>
<BR><FONT SIZE=3D2>processor-dependent anyway and is not necessarily =
the same</FONT>
<BR><FONT SIZE=3D2>as HUGE(whatever) (though it is a bit hard to =
imagine how it</FONT>
<BR><FONT SIZE=3D2>could usefully be larger).</FONT>
</P>

<P><FONT SIZE=3D2>The only context in which I can see that might matter =
is in a</FONT>
<BR><FONT SIZE=3D2>type parameter inquiry (6.1.3).&nbsp; We don't =
appear to have defined</FONT>
<BR><FONT SIZE=3D2>the kind of a type parameter inquiry.&nbsp; Although =
we didn't say, I</FONT>
<BR><FONT SIZE=3D2>am assuming that a type parameter inquiry ought to =
&quot;return&quot; the</FONT>
<BR><FONT SIZE=3D2>kind of the type parameter it is inquiring about. =
Otherwise,</FONT>
<BR><FONT SIZE=3D2>there would be no way to inquire about the type =
parameter values</FONT>
<BR><FONT SIZE=3D2>of some derived type variables (if the values didn't =
fit in a</FONT>
<BR><FONT SIZE=3D2>default integer).&nbsp; We probably ought to =
explicitly say, though.</FONT>
</P>

<P><FONT SIZE=3D2>ANSWER:</FONT>
</P>

<P><FONT SIZE=3D2>Q1. The kind parameters of all the intrinsic types =
are of</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; default integer kind. The kind =
parameter of the intrinsic</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; character length parameter is =
processor-dependent.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; The support for this answer is as =
described in the question.</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; Edits are provided to make this =
answer explicit.</FONT>
</P>

<P><FONT SIZE=3D2>Q2. The kind parameter of a type inquiry is the same =
as that of</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; the type parameter inquired =
about. See page 123, lines 35-36.</FONT>
</P>

<P><FONT SIZE=3D2>Q3. The first write statement is guaranteed to print =
a .true. value;</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; it is processor dependent whether =
the second one prints a .true.</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; or .false. value.</FONT>
</P>

<P><FONT SIZE=3D2>EDITS:</FONT>
</P>

<P><FONT SIZE=3D2>All edits apply to 04-007.</FONT>
</P>

<P><FONT SIZE=3D2>At [36:14], [37:30], [39:15], [40:14], and [44:2], =
insert the</FONT>
<BR><FONT SIZE=3D2>following sentence before &quot;The =
kind&quot;:</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; The kind type parameter is of =
type default integer.</FONT>
</P>

<P><FONT SIZE=3D2>At [40:10], before &quot;its&quot;, insert &quot;its =
kind is processor-dependent</FONT>
<BR><FONT SIZE=3D2>and&quot;.</FONT>
</P>

<P><FONT SIZE=3D2>SUBMITTED BY: Richard Maine</FONT>
</P>

<P><FONT SIZE=3D2>HISTORY: 04-408&nbsp;&nbsp;&nbsp; m170&nbsp; F03/0020 =
Submitted</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
04-408r1&nbsp; m170&nbsp; Passed by J3 meeting</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
05-146&nbsp;&nbsp;&nbsp; m171&nbsp; Passed J3 letter ballot #10</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
N1658&nbsp;&nbsp;&nbsp;&nbsp; m176&nbsp; Passed WG5 ballot N1657</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
N1663&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Reaffirmed in WG5 ballot N1661 on N1660</FONT>
</P>

<P><FONT =
SIZE=3D2>---------------------------------------------------------------=
-------</FONT>
</P>

<P><FONT SIZE=3D2>NUMBER: F03/0023</FONT>
<BR><FONT SIZE=3D2>TITLE: IEEE_SET/GET_UNDERFLOW_MODE</FONT>
<BR><FONT SIZE=3D2>KEYWORDS: IEEE, underflow mode</FONT>
<BR><FONT SIZE=3D2>DEFECT TYPE: Erratum</FONT>
<BR><FONT SIZE=3D2>STATUS: Passed by WG5 ballot</FONT>
</P>

<P><FONT SIZE=3D2>QUESTION:</FONT>
</P>

<P><FONT SIZE=3D2>Is it allowed for the argument of =
IEEE_SET_UNDERFLOW_MODE or</FONT>
<BR><FONT SIZE=3D2>IEEE_GET_UNDERFLOW_MODE to be an array?</FONT>
</P>

<P><FONT SIZE=3D2>There appears to be no restriction against arrays in =
these</FONT>
<BR><FONT SIZE=3D2>procedures.&nbsp; For IEEE_SET_UNDERFLOW_MODE, it is =
ill-defined</FONT>
<BR><FONT SIZE=3D2>what an array would mean.&nbsp; The wording implies =
a scalar, in</FONT>
<BR><FONT SIZE=3D2>that it talks about being true or false, but the =
restriction</FONT>
<BR><FONT SIZE=3D2>to scalars is not explicit. For =
IEEE_GET_UNDERFLOW_MODE, it</FONT>
<BR><FONT SIZE=3D2>could be defined, but seems a little silly and =
nonparallel.</FONT>
</P>

<P><FONT SIZE=3D2>The similar procedures for rounding mode do =
explicitly</FONT>
<BR><FONT SIZE=3D2>specify that their arguments are scalar.</FONT>
</P>

<P><FONT SIZE=3D2>ANSWER:</FONT>
</P>

<P><FONT SIZE=3D2>No, arrays are not allowed for these arguments.&nbsp; =
Edits are provided</FONT>
<BR><FONT SIZE=3D2>to correct this error.</FONT>
</P>

<P><FONT SIZE=3D2>EDITS:</FONT>
</P>

<P><FONT SIZE=3D2>[374:21] Add &quot;scalar and&quot; after &quot;shall =
be&quot;</FONT>
<BR><FONT SIZE=3D2>[380:13] Add &quot;scalar and&quot; after =
&quot;shall be&quot;</FONT>
</P>

<P><FONT SIZE=3D2>SUBMITTED BY: Richard Maine</FONT>
</P>

<P><FONT SIZE=3D2>HISTORY: 04-420&nbsp;&nbsp;&nbsp; m170&nbsp; F03/0023 =
Submitted - Passed by J3 meeting</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
05-146&nbsp;&nbsp;&nbsp; m171&nbsp; Passed J3 letter ballot #10</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
N1658&nbsp;&nbsp;&nbsp;&nbsp; m176&nbsp; Passed WG5 ballot N1657</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
N1663&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Reaffirmed in WG5 ballot N1661 on N1660</FONT>
</P>

<P><FONT =
SIZE=3D2>---------------------------------------------------------------=
-------</FONT>
</P>

<P><FONT SIZE=3D2>NUMBER: F03/0025</FONT>
<BR><FONT SIZE=3D2>TITLE: Abstract types in CLASS IS type guard =
statements</FONT>
<BR><FONT SIZE=3D2>KEYWORDS: ABSTRACT, CLASS IS, type guard, SELECT =
TYPE</FONT>
<BR><FONT SIZE=3D2>DEFECT TYPE: Erratum</FONT>
<BR><FONT SIZE=3D2>STATUS: Passed by WG5 ballot</FONT>
</P>

<P><FONT SIZE=3D2>QUESTION:</FONT>
</P>

<P><FONT SIZE=3D2>Consider the following program:</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; PROGRAM foo</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; TYPE, =
ABSTRACT :: base</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; INTEGER =
i</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; END =
TYPE</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; TYPE, =
EXTENDS(base) :: child</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; INTEGER =
j</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; END =
TYPE</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CLASS(*), =
POINTER :: x</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
TYPE(child), TARGET :: c1</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; x =3D&gt; =
c1</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SELECT =
TYPE (x)</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CLASS =
IS (base)</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; PRINT *, 'Class is base'</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CLASS =
DEFAULT</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; PRINT *, 'Class is not base'</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; END =
SELECT</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; END</FONT>
</P>

<P><FONT SIZE=3D2>Constraint C401 seems to prohibit the abstract type =
&quot;base&quot; from</FONT>
<BR><FONT SIZE=3D2>appearing in a CLASS IS type guard statement, thus =
prohibiting this</FONT>
<BR><FONT SIZE=3D2>program.&nbsp; There seems to be no reason to =
prohibit this, and allowing</FONT>
<BR><FONT SIZE=3D2>it seems to be useful in some situations.</FONT>
</P>

<P><FONT SIZE=3D2>Was this program intended to be =
standard-conforming?</FONT>
</P>

<P><FONT SIZE=3D2>ANSWER:</FONT>
</P>

<P><FONT SIZE=3D2>Yes, this program was intended to be =
standard-conforming.&nbsp; Edits are</FONT>
<BR><FONT SIZE=3D2>provided to correct this oversight.</FONT>
</P>

<P><FONT SIZE=3D2>EDITS:</FONT>
</P>

<P><FONT SIZE=3D2>All edits refer to 04-007.</FONT>
<BR><FONT SIZE=3D2>[162:17] Change &quot;&lt;type-spec&gt;&quot; to =
&quot;&lt;derived-type-spec&gt;&quot;.</FONT>
<BR><FONT SIZE=3D2>[162:19] After &quot;&lt;type-spec&gt;&quot;, insert =
&quot;or &lt;derived-type-spec&gt;&quot;.</FONT>
<BR><FONT SIZE=3D2>[162:20] After &quot;&lt;type-spec&gt;&quot;, insert =
&quot;or &lt;derived-type-spec&gt;&quot;.</FONT>
<BR><FONT SIZE=3D2>[162:21] After &quot;&lt;type-spec&gt;&quot;, insert =
&quot;or &lt;derived-type-spec&gt;&quot;.</FONT>
</P>

<P><FONT SIZE=3D2>SUBMITTED BY: Rob James</FONT>
</P>

<P><FONT SIZE=3D2>HISTORY: 04-411&nbsp;&nbsp;&nbsp; m170&nbsp; F03/0025 =
Submitted</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
04-411r1&nbsp; m170&nbsp; Passed by J3 meeting</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
05-146&nbsp;&nbsp;&nbsp; m171&nbsp; Passed J3 letter ballot #10</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
N1658&nbsp;&nbsp;&nbsp;&nbsp; m176&nbsp; Passed WG5 ballot N1657</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
N1663&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Reaffirmed in WG5 ballot N1661 on N1660</FONT>
</P>

<P><FONT =
SIZE=3D2>---------------------------------------------------------------=
-------</FONT>
</P>

<P><FONT SIZE=3D2>NUMBER: F03/0026</FONT>
<BR><FONT SIZE=3D2>TITLE: Intrinsic types in CLASS IS type guard =
statements</FONT>
<BR><FONT SIZE=3D2>KEYWORDS: CLASS IS, type guard, SELECT TYPE, =
intrinsic type</FONT>
<BR><FONT SIZE=3D2>DEFECT TYPE: Erratum</FONT>
<BR><FONT SIZE=3D2>STATUS: Passed by WG5 ballot</FONT>
</P>

<P><FONT SIZE=3D2>QUESTION:</FONT>
</P>

<P><FONT SIZE=3D2>Consider the following program:</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; PROGRAM foo</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CLASS(*), =
POINTER :: x</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; INTEGER, =
TARGET :: i</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; x =3D&gt; =
i</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SELECT =
TYPE (x)</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CLASS =
IS (INTEGER)</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; PRINT *, 'How can INTEGER be a class?'</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; END =
SELECT</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; END</FONT>
</P>

<P><FONT SIZE=3D2>The description of a CLASS IS type guard statement =
refers to an</FONT>
<BR><FONT SIZE=3D2>extension of the type specified.&nbsp; This makes no =
sense for</FONT>
<BR><FONT SIZE=3D2>nonextensible types.&nbsp; C815 disallows all =
nonextensible derived types,</FONT>
<BR><FONT SIZE=3D2>but nothing disallows intrinsic types, which are =
also nonextensible.</FONT>
</P>

<P><FONT SIZE=3D2>Was this program intended to be =
standard-conforming?</FONT>
</P>

<P><FONT SIZE=3D2>ANSWER:</FONT>
</P>

<P><FONT SIZE=3D2>No, this program was not intended to be =
standard-conforming.&nbsp; Edits</FONT>
<BR><FONT SIZE=3D2>are supplied to correct this oversight.</FONT>
</P>

<P><FONT SIZE=3D2>EDITS:</FONT>
</P>

<P><FONT SIZE=3D2>All edits refer to 04-007.&nbsp; Note that these =
edits are the same as the</FONT>
<BR><FONT SIZE=3D2>edits proposed for F03/0025.</FONT>
</P>

<P><FONT SIZE=3D2>[162:17] Change &quot;&lt;type-spec&gt;&quot; to =
&quot;&lt;derived-type-spec&gt;&quot;.</FONT>
<BR><FONT SIZE=3D2>[162:19] After &quot;&lt;type-spec&gt;&quot;, insert =
&quot;or &lt;derived-type-spec&gt;&quot;.</FONT>
<BR><FONT SIZE=3D2>[162:20] After &quot;&lt;type-spec&gt;&quot;, insert =
&quot;or &lt;derived-type-spec&gt;&quot;.</FONT>
<BR><FONT SIZE=3D2>[162:21] After &quot;&lt;type-spec&gt;&quot;, insert =
&quot;or &lt;derived-type-spec&gt;&quot;.</FONT>
</P>

<P><FONT SIZE=3D2>SUBMITTED BY: Rob James</FONT>
</P>

<P><FONT SIZE=3D2>HISTORY: 04-412&nbsp;&nbsp;&nbsp; m170&nbsp; F03/0026 =
Submitted</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
04-412r1&nbsp; m170&nbsp; Passed by J3 meeting</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
05-146&nbsp;&nbsp;&nbsp; m171&nbsp; Passed J3 letter ballot #10</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
N1658&nbsp;&nbsp;&nbsp;&nbsp; m176&nbsp; Passed WG5 ballot N1657</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
N1663&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Reaffirmed in WG5 ballot N1661 on N1660</FONT>
</P>

<P><FONT =
SIZE=3D2>---------------------------------------------------------------=
-------</FONT>
</P>

<P><FONT SIZE=3D2>NUMBER: F03/0027</FONT>
<BR><FONT SIZE=3D2>TITLE: Assumed character length in type guard =
statements</FONT>
<BR><FONT SIZE=3D2>KEYWORDS: CHARACTER, assumed length, type guard, =
SELECT TYPE</FONT>
<BR><FONT SIZE=3D2>DEFECT TYPE: Erratum</FONT>
<BR><FONT SIZE=3D2>STATUS: Passed by WG5 ballot</FONT>
</P>

<P><FONT SIZE=3D2>QUESTION:</FONT>
</P>

<P><FONT SIZE=3D2>Consider the following program:</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; PROGRAM foo</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
CHARACTER, TARGET :: c</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CLASS(*), =
POINTER :: p</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; p =3D&gt; =
c</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SELECT =
TYPE (p)</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; TYPE IS =
(CHARACTER(*))</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; PRINT *, 'Character of length ', LEN(p)</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; END =
SELECT</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; END</FONT>
</P>

<P><FONT SIZE=3D2>Constraint C814 says that, in a type guard statement, =
the &lt;type-spec&gt;</FONT>
<BR><FONT SIZE=3D2>shall specify that each length type parameter is =
assumed.</FONT>
</P>

<P><FONT SIZE=3D2>Constraint C416 does not list a type guard statement =
as a context in</FONT>
<BR><FONT SIZE=3D2>which &quot;*&quot; can be used as a length type =
parameter for a character.</FONT>
</P>

<P><FONT SIZE=3D2>Was this program intended to be =
standard-conforming?</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>ANSWER:</FONT>
</P>

<P><FONT SIZE=3D2>Yes, this program was intended to be =
standard-conforming.&nbsp; Edits are</FONT>
<BR><FONT SIZE=3D2>supplied to correct this oversight.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>EDITS:</FONT>
</P>

<P><FONT SIZE=3D2>All edits refer to 04-007.&nbsp; These edits assume =
that the edits for</FONT>
<BR><FONT SIZE=3D2>F03/0026 are passed.</FONT>
</P>

<P><FONT SIZE=3D2>[41:9]&nbsp;&nbsp; Remove &quot;or&quot;.</FONT>
<BR><FONT SIZE=3D2>[41:9+]&nbsp; Add a new list item:</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&quot;(3.5) in the &lt;type-spec&gt; or &lt;derived-type-spec&gt; of a =
type</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; guard =
statement (8.1.5),</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
or&quot;</FONT>
<BR><FONT SIZE=3D2>[41:33+] Add a new list item:</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&quot;(3.5) If used in the &lt;type-spec&gt; of a type guard =
statement,</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the =
associating entity assumes its length from the selector.&quot;</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>SUBMITTED BY: Rob James</FONT>
</P>

<P><FONT SIZE=3D2>HISTORY: 04-413&nbsp;&nbsp;&nbsp; m170&nbsp; F03/0027 =
Submitted</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
04-413r1&nbsp; m170&nbsp; Passed by J3 meeting</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
05-146&nbsp;&nbsp;&nbsp; m171&nbsp; Passed J3 letter ballot #10</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
N1658&nbsp;&nbsp;&nbsp;&nbsp; m176&nbsp; Passed WG5 ballot N1657 - fix =
edits</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
N1663&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Reaffirmed in WG5 ballot N1661 on N1660 - fix</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; edits</FONT>
</P>

<P><FONT =
SIZE=3D2>---------------------------------------------------------------=
-------</FONT>
</P>

<P><FONT SIZE=3D2>NUMBER: F03/0028</FONT>
<BR><FONT SIZE=3D2>TITLE: Commas in complex namelist output</FONT>
<BR><FONT SIZE=3D2>KEYWORDS: Namelist, complex formatting, comma, =
semicolon</FONT>
<BR><FONT SIZE=3D2>DEFECT TYPE: Erratum</FONT>
<BR><FONT SIZE=3D2>STATUS: Passed by WG5 ballot</FONT>
</P>

<P><FONT SIZE=3D2>QUESTION:</FONT>
</P>

<P><FONT SIZE=3D2>The 7th paragraph in 10.9.2 for list directed output =
says:</FONT>
</P>

<P><FONT SIZE=3D2>&quot;Complex constants are enclosed in parentheses =
with a</FONT>
<BR><FONT SIZE=3D2>separator between the real and imaginary parts, =
each</FONT>
<BR><FONT SIZE=3D2>produced as defined above for real constants. The =
separator</FONT>
<BR><FONT SIZE=3D2>is a comma if the decimal edit mode is POINT; it is =
a</FONT>
<BR><FONT SIZE=3D2>semicolon if the decimal edit mode is COMMA.&quot;</F=
ONT>
</P>

<P><FONT SIZE=3D2>There are similar words in most other places where =
complex</FONT>
<BR><FONT SIZE=3D2>formatting is described.</FONT>
</P>

<P><FONT SIZE=3D2>The second paragraph of 10.10.1.3 Namelist group =
object list</FONT>
<BR><FONT SIZE=3D2>items says:</FONT>
</P>

<P><FONT SIZE=3D2>&quot;When the next effective item is of type =
complex, the input</FONT>
<BR><FONT SIZE=3D2>form of the input value consists of a left =
parenthesis</FONT>
<BR><FONT SIZE=3D2>followed by an ordered pair of numeric input =
fields</FONT>
<BR><FONT SIZE=3D2>separated by a comma and followed by a right =
parenthesis. &quot;</FONT>
</P>

<P><FONT SIZE=3D2>Other places correctly describe namelist complex =
output as</FONT>
<BR><FONT SIZE=3D2>having a separator, either a comma or a semicolon, =
depending</FONT>
<BR><FONT SIZE=3D2>on the decimal edit mode.</FONT>
</P>

<P><FONT SIZE=3D2>Should the namelist version be reworded to say =
&quot;comma or</FONT>
<BR><FONT SIZE=3D2>semicolon&quot;?</FONT>
</P>

<P><FONT SIZE=3D2>ANSWER:</FONT>
</P>

<P><FONT SIZE=3D2>Yes.&nbsp; Edits are supplied to correct this =
oversight.</FONT>
<BR><FONT SIZE=3D2>In addition, a similar issue exists for list =
directed input of</FONT>
<BR><FONT SIZE=3D2>undelimited character values and namelist output of =
character</FONT>
<BR><FONT SIZE=3D2>values.</FONT>
</P>

<P><FONT SIZE=3D2>EDITS:</FONT>
</P>

<P><FONT SIZE=3D2>All edits refer to 04-007.</FONT>
</P>

<P><FONT SIZE=3D2>[240:13] Replace &quot;comma&quot; with &quot;comma =
(if the decimal edit mode is</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
POINT), semicolon (if the decimal edit mode is COMMA)&quot;.</FONT>
</P>

<P><FONT SIZE=3D2>[244:29] Replace &quot;a comma&quot; by &quot;a comma =
(if the decimal edit mode</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; is =
POINT) or a semicolon (if the decimal edit mode is</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
COMMA),&quot;.</FONT>
<BR><FONT SIZE=3D2>[244:30] Before &quot;The first&quot;, add the =
following sentence:</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
The separator is a comma if the decimal edit mode is</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
POINT; it is a semicolon if the decimal edit mode is</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
COMMA.</FONT>
<BR><FONT SIZE=3D2>[244:32] Replace &quot;comma&quot; with =
&quot;separator&quot;.</FONT>
<BR><FONT SIZE=3D2>[244:33] Replace &quot;comma&quot; with =
&quot;separator&quot;.</FONT>
</P>

<P><FONT SIZE=3D2>[245:4] After &quot;comma,&quot; insert &quot; =
semicolon,&quot;.</FONT>
</P>

<P><FONT SIZE=3D2>SUBMITTED BY: Dick Hendrickson</FONT>
</P>

<P><FONT SIZE=3D2>HISTORY: 04-409&nbsp;&nbsp;&nbsp; m170&nbsp; F03/0028 =
Submitted</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
04-409r1&nbsp; m170&nbsp; Passed by J3 meeting</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
05-146&nbsp;&nbsp;&nbsp; m171&nbsp; Failed interp letter ballot =
#10</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
05-164&nbsp;&nbsp;&nbsp; m171&nbsp; Passed by J3 meeting</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
05-170&nbsp;&nbsp;&nbsp; m172&nbsp; Failed J3 letter ballot #11</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
05-257&nbsp;&nbsp;&nbsp; m173&nbsp; Passed by J3 meeting</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
06-133&nbsp;&nbsp;&nbsp; m175&nbsp; Passed J3 letter ballot #12</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
N1658&nbsp;&nbsp;&nbsp;&nbsp; m176&nbsp; Passed WG5 ballot N1657 - fix =
edits</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
N1663&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Reaffirmed in WG5 ballot N1661 on N1660</FONT>
</P>

<P><FONT =
SIZE=3D2>---------------------------------------------------------------=
-------</FONT>
</P>

<P><FONT SIZE=3D2>NUMBER: F03/0029</FONT>
<BR><FONT SIZE=3D2>TITLE: Negative zero and intrinsic functions</FONT>
<BR><FONT SIZE=3D2>KEYWORDS: Negative zero, IEEE, intrinsic =
functions</FONT>
<BR><FONT SIZE=3D2>DEFECT TYPE: Erratum</FONT>
<BR><FONT SIZE=3D2>STATUS: Passed by WG5 ballot</FONT>
</P>

<P><FONT SIZE=3D2>QUESTION:</FONT>
</P>

<P><FONT SIZE=3D2>4.4.2 states</FONT>
<BR><FONT SIZE=3D2>&nbsp; &quot;Processors that distinguish between =
positive and negative zeros</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; shall treat them as equivalent ... as =
actual arguments to intrinsic</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; procedures other than those for which =
it is explicitly specified</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; that negative zero is =
distinguished&quot;</FONT>
</P>

<P><FONT SIZE=3D2>Q1. Does this mean that TRANSFER(-0.0,42) is required =
to give the same</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; answer as =
TRANSFER(+0.0,42)?&nbsp; The definition of TRANSFER has no</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; explicit mention of negative =
zero.</FONT>
</P>

<P><FONT SIZE=3D2>Q2. Does this mean that MERGE(+0.0,-0.0,flag) always =
returns +0.0?</FONT>
</P>

<P><FONT SIZE=3D2>Q3. Does this mean that SPREAD(-0.0,2) has the value =
[+0.0,+0.0]</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; instead of [-0.0,-0.0]?</FONT>
</P>

<P><FONT SIZE=3D2>Q4. Does this mean that RESHAPE([-0.0],[1]) has the =
value [+0.0]</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; instead of [-0.0]?</FONT>
</P>

<P><FONT SIZE=3D2>Q5. Does this mean that SET_EXPONENT(-0.0,10) is +0.0 =
not -0.0?</FONT>
</P>

<P><FONT SIZE=3D2>Q6. Does this mean that if a REAL variable X has a =
negative zero</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; value, REAL(x,...) has a positive =
zero value?</FONT>
</P>

<P><FONT SIZE=3D2>Q7. Does this mean that CMPLX(0,-0.0) has the value =
(+0.0,+0.0)</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; instead of (+0.0,-0.0)?</FONT>
</P>

<P><FONT SIZE=3D2>Q8. Does this mean that if a complex variable C has a =
negative zero</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; imaginary part, that AIMAG(C) =
returns +0.0 instead of -0.0?</FONT>
</P>

<P><FONT SIZE=3D2>Q9. In any other intrinsic function, if the =
definition of the</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; intrinsic would imply a different =
result for negative zero than</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; for positive zero, does this mean =
that the function returns the</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; positive zero answer for a =
negative zero argument?</FONT>
</P>

<P><FONT SIZE=3D2>ANSWER:</FONT>
</P>

<P><FONT SIZE=3D2>Q1.&nbsp; No.&nbsp; The definition of TRANSFER =
explicitly states that its result</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp; has the same physical =
representation as its first argument.&nbsp; This</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp; would not be possible if =
&quot;equivalent&quot; meant that the exact same</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp; result had to be =
produced.</FONT>
</P>

<P><FONT SIZE=3D2>Q2.&nbsp; No, this would contradict the definition of =
MERGE.</FONT>
</P>

<P><FONT SIZE=3D2>Q3.&nbsp; No.&nbsp; SPREAD &quot;replicates&quot; its =
argument, which means that the value</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp; of each copy is the same as =
the original, not just compare equal.</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp; As with TRANSFER, this =
would not be possible with the suggested</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp; interpretation of the text =
in 4.4.2.</FONT>
</P>

<P><FONT SIZE=3D2>Q4+.&nbsp; No.&nbsp; As with the previous questions, =
this would require an</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; overly strict =
interpretation of the term &quot;equivalent&quot;,</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; contradicting the =
clear intent of the function in question.</FONT>
</P>

<P><FONT SIZE=3D2>DISCUSSION:</FONT>
</P>

<P><FONT SIZE=3D2>The term &quot;equivalent&quot; in the quoted text in =
4.4.2 refers to the</FONT>
<BR><FONT SIZE=3D2>concept of mathematical equivalence, not physical or =
computational</FONT>
<BR><FONT SIZE=3D2>equivalence.&nbsp; A clarifying edit is =
supplied.</FONT>
</P>

<P><FONT SIZE=3D2>EDITS:</FONT>
</P>

<P><FONT SIZE=3D2>[38:2] Before &quot;equivalent&quot; insert =
&quot;mathematically&quot;.</FONT>
</P>

<P><FONT SIZE=3D2>SUBMITTED BY: Malcolm Cohen</FONT>
</P>

<P><FONT SIZE=3D2>HISTORY: 04-422&nbsp;&nbsp;&nbsp; m170&nbsp; F03/0029 =
Submitted - Passed by J3 meeting</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
05-146&nbsp;&nbsp;&nbsp; m171&nbsp; Passed J3 letter ballot #10</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
N1658&nbsp;&nbsp;&nbsp;&nbsp; m176&nbsp; Passed WG5 ballot N1657</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
N1663&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Reaffirmed in WG5 ballot N1661 on N1660</FONT>
</P>

<P><FONT =
SIZE=3D2>---------------------------------------------------------------=
-------</FONT>
</P>

<P><FONT SIZE=3D2>NUMBER: F03/0045</FONT>
<BR><FONT SIZE=3D2>TITLE: Finalization and assumed-size arguments with =
INTENT(OUT)</FONT>
<BR><FONT SIZE=3D2>KEYWORDS: finalization, INTENT(OUT), assumed size, =
dummy argument</FONT>
<BR><FONT SIZE=3D2>DEFECT TYPE: Erratum</FONT>
<BR><FONT SIZE=3D2>STATUS: Passed by WG5 ballot</FONT>
</P>

<P><FONT SIZE=3D2>QUESTION:</FONT>
</P>

<P><FONT SIZE=3D2>Consider the following program:</FONT>
</P>

<P><FONT SIZE=3D2>MODULE m</FONT>
<BR><FONT SIZE=3D2>&nbsp; TYPE t</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; INTEGER :: i</FONT>
<BR><FONT SIZE=3D2>&nbsp; CONTAINS</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; FINAL :: finalizeT</FONT>
<BR><FONT SIZE=3D2>&nbsp; END TYPE</FONT>
<BR><FONT SIZE=3D2>CONTAINS</FONT>
<BR><FONT SIZE=3D2>&nbsp; ELEMENTAL SUBROUTINE finalizeT(f)</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; TYPE(t), INTENT(INOUT) :: =
f</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; f%i =3D 10</FONT>
<BR><FONT SIZE=3D2>&nbsp; END SUBROUTINE</FONT>
<BR><FONT SIZE=3D2>END MODULE</FONT>
</P>

<P><FONT SIZE=3D2>SUBROUTINE xyz (d)</FONT>
<BR><FONT SIZE=3D2>&nbsp; USE m</FONT>
<BR><FONT SIZE=3D2>&nbsp; TYPE(t), INTENT(OUT) :: d(*)</FONT>
<BR><FONT SIZE=3D2>END SUBROUTINE</FONT>
</P>

<P><FONT SIZE=3D2>PROGRAM foo</FONT>
<BR><FONT SIZE=3D2>&nbsp; USE m</FONT>
<BR><FONT SIZE=3D2>&nbsp; EXTERNAL xyz</FONT>
<BR><FONT SIZE=3D2>&nbsp; TYPE(t) :: a(10) =3D t(5)</FONT>
<BR><FONT SIZE=3D2>&nbsp; CALL xyz(a(2))</FONT>
<BR><FONT SIZE=3D2>END PROGRAM</FONT>
</P>

<P><FONT SIZE=3D2>4.5.5.2 of Fortran 2003 states:</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; When a procedure is invoked, a =
nonpointer, nonallocatable object</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; that is an actual argument =
associated with an INTENT(OUT) dummy</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; argument is finalized.</FONT>
</P>

<P><FONT SIZE=3D2>For assumed-size arguments, this situation is similar =
to that of</FONT>
<BR><FONT SIZE=3D2>default initialization with INTENT(OUT).&nbsp; =
Default initialization is</FONT>
<BR><FONT SIZE=3D2>prohibited for INTENT(OUT), assumed-size dummy =
arguments by C544.&nbsp; A</FONT>
<BR><FONT SIZE=3D2>similar restriction on finalization may have been =
overlooked.</FONT>
</P>

<P><FONT SIZE=3D2>Was this program intended to be =
standard-conforming?</FONT>
</P>

<P><FONT SIZE=3D2>ANSWER:</FONT>
</P>

<P><FONT SIZE=3D2>No, this program was not intended to be =
standard-conforming.&nbsp; An edit</FONT>
<BR><FONT SIZE=3D2>is supplied to correct this oversight.</FONT>
</P>

<P><FONT SIZE=3D2>DISCUSSION:</FONT>
</P>

<P><FONT SIZE=3D2>The unstated philosophy of assumed-size arrays in the =
standard is that</FONT>
<BR><FONT SIZE=3D2>no action is allowed on an assumed-size array which =
would need to be</FONT>
<BR><FONT SIZE=3D2>applied elementally to the whole array.&nbsp; That =
is why no whole array</FONT>
<BR><FONT SIZE=3D2>assignment is allowed, for example.</FONT>
</P>

<P><FONT SIZE=3D2>In accordance with this philosophy,</FONT>
<BR><FONT SIZE=3D2>(1) types with ultimate allocatable components also =
need to be</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; excluded from being INTENT(OUT) =
assumed-size, as procedure</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; invocation in this case requires =
deallocation of all the</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; allocated components.</FONT>
</P>

<P><FONT SIZE=3D2>(2) polymorphic INTENT(OUT) assumed-size arrays =
should also be</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; excluded, as they might have =
finalisation, default initialisation</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; or allocatable components.</FONT>
</P>

<P><FONT SIZE=3D2>This interp subsumes Fortran 2003 interp =
#0060.</FONT>
</P>

<P><FONT SIZE=3D2>EDITS:</FONT>
</P>

<P><FONT SIZE=3D2>All edits refer to 04-007.</FONT>
</P>

<P><FONT SIZE=3D2>[80:9]&nbsp; Before &quot;of a type&quot;, =
insert</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&quot;polymorphic, of a finalizable type, of a type with an</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
ultimate allocatable component, or&quot;.</FONT>
</P>

<P><FONT SIZE=3D2>SUBMITTED BY: Rob James</FONT>
</P>

<P><FONT SIZE=3D2>HISTORY: 05-136&nbsp;&nbsp;&nbsp; m171&nbsp; F03/0045 =
Submitted, passed by J3 meeting</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
05-170&nbsp;&nbsp;&nbsp; m172&nbsp; Passed J3 letter ballot #11</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
N1622&nbsp;&nbsp;&nbsp;&nbsp; m172&nbsp; Failed WG5 ballot N1629</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
05-256&nbsp;&nbsp;&nbsp; m173&nbsp; Passed by J3 meeting</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
06-133&nbsp;&nbsp;&nbsp; m175&nbsp; Passed J3 letter ballot #12</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
N1658&nbsp;&nbsp;&nbsp;&nbsp; m176&nbsp; Passed WG5 ballot N1657</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
N1663&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Reaffirmed in WG5 ballot N1661 on N1660</FONT>
</P>

<P><FONT =
SIZE=3D2>---------------------------------------------------------------=
-------</FONT>
</P>

<P><FONT SIZE=3D2>NUMBER: F03/0056</FONT>
<BR><FONT SIZE=3D2>TITLE: Null input values and list-directed =
UDDTIO</FONT>
<BR><FONT SIZE=3D2>KEYWORDS: null value, UDDTIO</FONT>
<BR><FONT SIZE=3D2>DEFECT TYPE: Interpretation</FONT>
<BR><FONT SIZE=3D2>STATUS: Passed by WG5 ballot</FONT>
</P>

<P><FONT SIZE=3D2>QUESTION:</FONT>
</P>

<P><FONT SIZE=3D2>Consider the following program:</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MODULE m</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
PRIVATE</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; TYPE, =
PUBLIC :: t</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; INTEGER =
i</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; INTEGER =
j</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
CONTAINS</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
PROCEDURE, PRIVATE :: readFormatted =3D&gt; readFormattedT</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; GENERIC =
:: READ(FORMATTED) =3D&gt; readFormatted</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; END =
TYPE</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CONTAINS</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
SUBROUTINE readformattedT(dtv, unit, iotype, v_list, iostat, =
iomsg)</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
CLASS(t),&nbsp;&nbsp;&nbsp;&nbsp; INTENT(INOUT) :: dtv</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
INTEGER,&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; INTENT(IN)&nbsp;&nbsp;&nbsp; :: =
unit</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
CHARACTER(*), INTENT(IN)&nbsp;&nbsp;&nbsp; :: iotype</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
INTEGER,&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; INTENT(IN)&nbsp;&nbsp;&nbsp; :: =
v_list(:)</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
INTEGER,&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; INTENT(OUT)&nbsp;&nbsp; :: =
iostat</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
CHARACTER(*), INTENT(INOUT) :: iomsg</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; READ =
(unit, *) dtv%i</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; READ =
(unit, *) dtv%j</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; END =
SUBROUTINE</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; END MODULE</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; PROGRAM p</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; USE =
m</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; INTEGER =
i</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; TYPE(t) =
x, y, z</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; x%i =3D =
10</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; x%j =3D =
15</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; y%i =3D =
20</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; y%j =3D =
25</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; z%i =3D =
30</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; z%j =3D =
35</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; i =3D =
100</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; READ =
(*,*) x, y, z, i</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; PRINT *, =
x, y, z, i</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; END PROGRAM</FONT>
</P>

<P><FONT SIZE=3D2>The following is given as input to this =
program:</FONT>
</P>

<P><FONT SIZE=3D2>1044 2167 3977 /</FONT>
<BR><FONT SIZE=3D2>1 2 3</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>10.9.1.1 of Fortran 2003 (Null values) states:</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; A slash encountered as a value =
separator during execution of a</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; list-directed input statement =
causes termination of execution of</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; that input statement after the =
assignment of the previous value.</FONT>
</P>

<P><FONT SIZE=3D2>If a child data transfer statement encounters a slash =
as a value</FONT>
<BR><FONT SIZE=3D2>separator, it is unclear whether this statement =
applies to just the</FONT>
<BR><FONT SIZE=3D2>child statement, or to the parent data transfer =
statement as well.</FONT>
<BR><FONT SIZE=3D2>The significance for any subsequent child statement =
is also unclear.</FONT>
</P>

<P><FONT SIZE=3D2>What is the behaviour of this program when it is =
given the specified</FONT>
<BR><FONT SIZE=3D2>input?</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>ANSWER:</FONT>
</P>

<P><FONT SIZE=3D2>When a child data transfer statement encounters a =
slash as a value</FONT>
<BR><FONT SIZE=3D2>separator, only that data transfer statement =
encounters the slash.</FONT>
<BR><FONT SIZE=3D2>None of its parent data transfer statements =
encounters the slash.</FONT>
<BR><FONT SIZE=3D2>Only the data transfer statement that encounters the =
slash is</FONT>
<BR><FONT SIZE=3D2>terminated.</FONT>
</P>

<P><FONT SIZE=3D2>The program above should print the following:</FONT>
<BR><FONT SIZE=3D2>&nbsp;1044.2167.3977.25.1.2.3</FONT>
<BR><FONT SIZE=3D2>where &quot;.&quot; represents a value =
separator.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>EDITS:</FONT>
</P>

<P><FONT SIZE=3D2>None.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>SUBMITTED BY: Rob James</FONT>
</P>

<P><FONT SIZE=3D2>HISTORY: 05-171&nbsp;&nbsp;&nbsp; m172&nbsp; F03/0056 =
Submitted</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
05-218&nbsp;&nbsp;&nbsp; m173&nbsp; Passed by J3 meeting</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
06-133&nbsp;&nbsp;&nbsp; m175&nbsp; Passed J3 letter ballot #12</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
N1658&nbsp;&nbsp;&nbsp;&nbsp; m176&nbsp; Passed WG5 ballot N1657</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
N1663&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Reaffirmed in WG5 ballot N1661 on N1660</FONT>
</P>

<P><FONT =
SIZE=3D2>---------------------------------------------------------------=
-------</FONT>
</P>

<P><FONT SIZE=3D2>NUMBER: F03/0057</FONT>
<BR><FONT SIZE=3D2>TITLE: Namelist I/O and UDDTIO</FONT>
<BR><FONT SIZE=3D2>KEYWORDS: namelist, UDDTIO</FONT>
<BR><FONT SIZE=3D2>DEFECT TYPE: Erratum</FONT>
<BR><FONT SIZE=3D2>STATUS: Passed by WG5 ballot</FONT>
</P>

<P><FONT SIZE=3D2>QUESTION:</FONT>
</P>

<P><FONT SIZE=3D2>Can namelist I/O ever invoke a user-defined =
derived-type I/O</FONT>
<BR><FONT SIZE=3D2>procedure?</FONT>
</P>

<P><FONT SIZE=3D2>10.10.1.2 of Fortran 2003 (Namelist input values) =
implies that</FONT>
<BR><FONT SIZE=3D2>namelist input cannot invoke a user-defined =
derived-type I/O</FONT>
<BR><FONT SIZE=3D2>procedure.&nbsp; It says that, for a derived-type =
variable, &quot;the effect is</FONT>
<BR><FONT SIZE=3D2>as if the variable represented were expanded into a =
sequence of scalar</FONT>
<BR><FONT SIZE=3D2>list items of intrinsic data types&quot;, which =
would preclude any</FONT>
<BR><FONT SIZE=3D2>derived-type I/O.</FONT>
</P>

<P><FONT SIZE=3D2>However, the same sentence says that this is done =
&quot;in the same way</FONT>
<BR><FONT SIZE=3D2>that formatted input/output list items are expanded =
(9.5.2)&quot;, which</FONT>
<BR><FONT SIZE=3D2>would result in some effective list items of derived =
type.</FONT>
</P>

<P><FONT SIZE=3D2>9.5.3.6 and 9.5.3.7.2 also imply that a user-defined =
derived-type I/O</FONT>
<BR><FONT SIZE=3D2>procedure could be invoked for a namelist group =
object.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>ANSWER:</FONT>
</P>

<P><FONT SIZE=3D2>Yes, namelist I/O can invoke a user-defined =
derived-type I/O</FONT>
<BR><FONT SIZE=3D2>procedure.&nbsp; Edits are provided to correct this =
problem.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>EDITS:</FONT>
</P>

<P><FONT SIZE=3D2>All edits refer to 04-007.</FONT>
</P>

<P><FONT SIZE=3D2>[244:8]&nbsp;&nbsp; Remove &quot;of intrinsic data =
types&quot;.</FONT>
</P>

<P><FONT SIZE=3D2>[244:10]&nbsp; Remove &quot;intrinsic&quot;.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>SUBMITTED BY: Rob James</FONT>
</P>

<P><FONT SIZE=3D2>HISTORY: 05-172&nbsp;&nbsp;&nbsp; m172&nbsp; F03/0057 =
Submitted</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
05-219&nbsp;&nbsp;&nbsp; m173&nbsp; Passed by J3 meeting</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
06-133&nbsp;&nbsp;&nbsp; m175&nbsp; Passed J3 letter ballot #12</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
N1658&nbsp;&nbsp;&nbsp;&nbsp; m176&nbsp; Passed WG5 ballot N1657</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
N1663&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Reaffirmed in WG5 ballot N1661 on N1660</FONT>
</P>

<P><FONT =
SIZE=3D2>---------------------------------------------------------------=
-------</FONT>
</P>

<P><FONT SIZE=3D2>NUMBER: F03/0058</FONT>
<BR><FONT SIZE=3D2>TITLE: Recursive namelist output</FONT>
<BR><FONT SIZE=3D2>KEYWORDS: UDDTIO, namelist, output</FONT>
<BR><FONT SIZE=3D2>DEFECT TYPE: Interpretation</FONT>
<BR><FONT SIZE=3D2>STATUS: Passed by WG5 ballot</FONT>
</P>

<P><FONT SIZE=3D2>QUESTION:</FONT>
</P>

<P><FONT SIZE=3D2>Consider the following program:</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MODULE mod</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
PRIVATE</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; TYPE, =
PUBLIC :: node</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; INTEGER :: value =3D 0</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
CONTAINS</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
PROCEDURE, PRIVATE :: nodeFormattedWrite =3D&gt; writeroutine</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; GENERIC =
:: WRITE(FORMATTED) =3D&gt; nodeFormattedWrite</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; END =
TYPE</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CONTAINS</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
SUBROUTINE writeroutine(dtv, unit, iotype, vlist, iostat, iomsg)</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
CLASS(node), INTENT(IN) :: dtv</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
INTEGER, INTENT(IN) :: unit</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
CHARACTER(LEN=3D*), INTENT(IN) :: iotype</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
INTEGER, INTENT(IN) :: vlist(:)</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
INTEGER, INTENT(OUT) :: iostat</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
CHARACTER(LEN=3D*), INTENT(INOUT) :: iomsg</FONT>
</P>

<P><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; REAL =
a</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
NAMELIST /inner/ a</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a =3D =
4.0</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
WRITE(unit, NML=3Dinner)</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; END =
SUBROUTINE</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; END MODULE</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; PROGRAM foo</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; USE =
mod</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
TYPE(node) :: a(2)</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; NAMELIST =
/outer/ a</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
a(1)%value =3D 1</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
a(2)%value =3D 2</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; WRITE(*, =
NML=3Douter)</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; END PROGRAM</FONT>
</P>

<P><FONT SIZE=3D2>Is the following output standard-conforming for the =
above program?&nbsp; If</FONT>
<BR><FONT SIZE=3D2>not, please give an example of standard-conforming =
output.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&amp;OUTER</FONT>
<BR><FONT SIZE=3D2>&nbsp;A=3D &amp;INNER</FONT>
<BR><FONT SIZE=3D2>&nbsp;A=3D4.000000000</FONT>
<BR><FONT SIZE=3D2>&nbsp;/,&nbsp; &amp;INNER</FONT>
<BR><FONT SIZE=3D2>&nbsp;A=3D4.000000000</FONT>
<BR><FONT SIZE=3D2>&nbsp;/</FONT>
<BR><FONT SIZE=3D2>&nbsp;/</FONT>
</P>

<P><FONT SIZE=3D2>ANSWER:</FONT>
</P>

<P><FONT SIZE=3D2>Yes</FONT>
</P>

<P><FONT SIZE=3D2>EDITS:</FONT>
</P>

<P><FONT SIZE=3D2>None</FONT>
</P>

<P><FONT SIZE=3D2>SUBMITTED BY: Rob James</FONT>
</P>

<P><FONT SIZE=3D2>HISTORY: 05-173&nbsp;&nbsp;&nbsp; m172&nbsp; F03/0058 =
Submitted</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
05-220&nbsp;&nbsp;&nbsp; m173&nbsp; Passed by J3 meeting</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
06-133&nbsp;&nbsp;&nbsp; m175&nbsp; Passed J3 letter ballot #12</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
N1658&nbsp;&nbsp;&nbsp;&nbsp; m176&nbsp; Passed WG5 ballot N1657</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
N1663&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Reaffirmed in WG5 ballot N1661 on N1660</FONT>
</P>

<P><FONT =
SIZE=3D2>---------------------------------------------------------------=
-------</FONT>
</P>

<P><FONT SIZE=3D2>NUMBER: F03/0060</FONT>
<BR><FONT SIZE=3D2>TITLE: Default initialization of INTENT(OUT), =
assumed-size arrays</FONT>
<BR><FONT SIZE=3D2>KEYWORDS: default initialization, INTENT(OUT), =
assumed size, polymorphism</FONT>
<BR><FONT SIZE=3D2>DEFECT TYPE: Erratum</FONT>
<BR><FONT SIZE=3D2>STATUS: Passed by WG5 ballot</FONT>
</P>

<P><FONT SIZE=3D2>QUESTION:</FONT>
</P>

<P><FONT SIZE=3D2>Consider the following program:</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MODULE m</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; TYPE =
base</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; INTEGER =
I</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; END =
TYPE</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; TYPE, =
EXTENDS(base) :: child</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; INTEGER =
:: j =3D 5</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; END =
TYPE</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CONTAINS</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
SUBROUTINE sub(b)</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
CLASS(base), INTENT(OUT) :: b(*)</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; END =
SUBROUTINE</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; END MODULE</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; PROGRAM foo</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; USE =
m</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
TYPE(child) :: c(3)</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; c%i =3D =
12</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; c%j =3D =
47</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CALL =
sub(c)</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; PRINT *, =
c%j</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; END PROGRAM</FONT>
</P>

<P><FONT SIZE=3D2>C544 prevents nonpolymorphic, INTENT(OUT), =
assumed-size arrays from</FONT>
<BR><FONT SIZE=3D2>having default initialization.&nbsp; The polymorphic =
case, however, is not</FONT>
<BR><FONT SIZE=3D2>checkable at compile time, so it cannot be a =
constraint.</FONT>
</P>

<P><FONT SIZE=3D2>Was it intended that the dynamic type of an =
INTENT(OUT), assumed-size</FONT>
<BR><FONT SIZE=3D2>array could have default initialization?&nbsp; If =
so, what does the above</FONT>
<BR><FONT SIZE=3D2>program print?</FONT>
</P>

<P><FONT SIZE=3D2>ANSWER:</FONT>
</P>

<P><FONT SIZE=3D2>No, this was not intended.</FONT>
</P>

<P><FONT SIZE=3D2>This interp is subsumed by Fortran 2003 interp # =
45,</FONT>
<BR><FONT SIZE=3D2>which contains edits making the above example =
non-conforming.</FONT>
</P>

<P><FONT SIZE=3D2>EDITS:</FONT>
</P>

<P><FONT SIZE=3D2>None</FONT>
</P>

<P><FONT SIZE=3D2>SUBMITTED BY: Rob James</FONT>
</P>

<P><FONT SIZE=3D2>HISTORY: 05-175&nbsp;&nbsp;&nbsp; m172&nbsp; F03/0060 =
Submitted</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
05-222&nbsp;&nbsp;&nbsp; m173&nbsp; Edit provided</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
05-222r1&nbsp; m173&nbsp; Subsumed by 0045 - Passed&nbsp; by J3 =
meeting</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
06-133&nbsp;&nbsp;&nbsp; m175&nbsp; Passed J3 letter ballot #12</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
N1658&nbsp;&nbsp;&nbsp;&nbsp; m176&nbsp; Passed WG5 ballot N1657</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
N1663&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Reaffirmed in WG5 ballot N1661 on N1660</FONT>
</P>

<P><FONT =
SIZE=3D2>---------------------------------------------------------------=
-------</FONT>
</P>

<P><FONT SIZE=3D2>NUMBER: F03/0061</FONT>
<BR><FONT SIZE=3D2>TITLE: Polymorphism and explicit-shape or =
assumed-size dummy arguments</FONT>
<BR><FONT SIZE=3D2>KEYWORDS: polymorphism, assumed size, actual =
argument, dummy argument</FONT>
<BR><FONT SIZE=3D2>DEFECT TYPE: Erratum</FONT>
<BR><FONT SIZE=3D2>STATUS: Passed by WG5 ballot</FONT>
</P>

<P><FONT SIZE=3D2>QUESTION:</FONT>
</P>

<P><FONT SIZE=3D2>Consider the following program:</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MODULE m</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; TYPE =
t1</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; INTEGER =
:: i</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; END =
TYPE</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CONTAINS</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
SUBROUTINE abc (b)</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
CLASS(t1) :: b(*)</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
EXTERNAL xyz</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CALL =
xyz(b(2))</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; END =
SUBROUTINE</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; END MODULE</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SUBROUTINE =
xyz(d)</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; USE =
m</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; TYPE(t1) =
:: d(2,3)</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; END SUBROUTINE</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; PROGRAM foo</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; USE =
m</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; TYPE, =
EXTENDS(t1) :: t2</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; INTEGER =
:: j</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; END =
TYPE</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; TYPE(t2) =
a(10)</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CALL =
abc(a(2))</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; END PROGRAM</FONT>
</P>

<P><FONT SIZE=3D2>During the execution of &quot;xyz&quot;, the dummy =
argument &quot;d&quot; is sequence</FONT>
<BR><FONT SIZE=3D2>associated with the associated actual argument =
(which is true if &quot;d&quot;</FONT>
<BR><FONT SIZE=3D2>has either explicit shape or assumed size).&nbsp; =
This implies that the</FONT>
<BR><FONT SIZE=3D2>entity that is argument associated with =
&quot;d&quot; must be contiguous.</FONT>
</P>

<P><FONT SIZE=3D2>The dummy argument &quot;b&quot; of the module =
subroutine &quot;abc&quot; is polymorphic,</FONT>
<BR><FONT SIZE=3D2>and its dynamic type in this case is different than =
its declared type.</FONT>
<BR><FONT SIZE=3D2>In this scoping unit, &quot;xyz&quot; has an =
implicit interface, so we know it</FONT>
<BR><FONT SIZE=3D2>doesn't have any polymorphic arguments.&nbsp; So, =
the dummy argument of</FONT>
<BR><FONT SIZE=3D2>&quot;xyz&quot; must be nonpolymorphic, and have the =
same declared type as the</FONT>
<BR><FONT SIZE=3D2>actual argument (b(2)).</FONT>
</P>

<P><FONT SIZE=3D2>This implies that we only want to pass the parent =
portion of b(2).</FONT>
<BR><FONT SIZE=3D2>But the dummy argument of &quot;xyz&quot; may be an =
explicit-shape or</FONT>
<BR><FONT SIZE=3D2>assumed-size array (in this case, it is an =
explicit-shape array).</FONT>
</P>

<P><FONT SIZE=3D2>This means that we have to pass a contiguous array to =
&quot;xyz&quot;.&nbsp; This</FONT>
<BR><FONT SIZE=3D2>wouldn't be a problem if the dynamic type of =
&quot;b&quot; was the same as the</FONT>
<BR><FONT SIZE=3D2>declared type, but in this case it is not.&nbsp; The =
parent portion of &quot;b&quot;</FONT>
<BR><FONT SIZE=3D2>(from element 2 to the end of the array) must be =
copied into a</FONT>
<BR><FONT SIZE=3D2>temporary array.</FONT>
</P>

<P><FONT SIZE=3D2>The compiler cannot possibly know how big =
&quot;b&quot; is because it is an</FONT>
<BR><FONT SIZE=3D2>assumed-size array, so it is impossible to make such =
a copy.</FONT>
</P>

<P><FONT SIZE=3D2>Was this program intended to be =
standard-conforming?</FONT>
</P>

<P><FONT SIZE=3D2>ANSWER:</FONT>
</P>

<P><FONT SIZE=3D2>No, this program was not intended to be =
standard-conforming.&nbsp; Edits</FONT>
<BR><FONT SIZE=3D2>are provided to correct this oversight.</FONT>
</P>

<P><FONT SIZE=3D2>EDITS:</FONT>
</P>

<P><FONT SIZE=3D2>All edits refer to 04-007.</FONT>
</P>

<P><FONT SIZE=3D2>[270:27]&nbsp; Change &quot;assumed-shape or =
pointer&quot; to &quot;assumed-shape,</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
pointer, or polymorphic&quot;.</FONT>
</P>

<P><FONT SIZE=3D2>SUBMITTED BY: Rob James</FONT>
</P>

<P><FONT SIZE=3D2>HISTORY: 05-176&nbsp;&nbsp;&nbsp; m172&nbsp; F03/0061 =
Submitted</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
05-223&nbsp;&nbsp;&nbsp; m173&nbsp; Passed by J3 meeting</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
06-133&nbsp;&nbsp;&nbsp; m175&nbsp; Passed J3 letter ballot #12</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
N1658&nbsp;&nbsp;&nbsp;&nbsp; m176&nbsp; Passed WG5 ballot N1657</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
N1663&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Reaffirmed in WG5 ballot N1661 on N1660</FONT>
</P>

<P><FONT =
SIZE=3D2>---------------------------------------------------------------=
-------</FONT>
</P>

<P><FONT SIZE=3D2>NUMBER: F03/0062</FONT>
<BR><FONT SIZE=3D2>TITLE: Finalization of array constructors</FONT>
<BR><FONT SIZE=3D2>KEYWORDS: Finalization, array constructor</FONT>
<BR><FONT SIZE=3D2>DEFECT TYPE: Erratum</FONT>
<BR><FONT SIZE=3D2>STATUS: Passed by WG5 ballot</FONT>
</P>

<P><FONT SIZE=3D2>QUESTION:</FONT>
</P>

<P><FONT SIZE=3D2>Consider the following program:</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MODULE m</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; TYPE =
t</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; INTEGER =
i</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
CONTAINS</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; FINAL =
:: finalizeT</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; END =
TYPE</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CONTAINS</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
SUBROUTINE finalizeT(obj)</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; TYPE(t) =
:: obj(:)</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; PRINT =
*, 'Finalizing a rank-1 array of type t'</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; END =
SUBROUTINE</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; END MODULE</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; PROGRAM foo</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; USE =
m</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; TYPE(t) =
:: a</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a%i =3D =
5</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; PRINT *, =
(/ (a, i=3D1,5) /)</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; END PROGRAM</FONT>
</P>

<P><FONT SIZE=3D2>If the PRINT statement in the main program was =
printing a function</FONT>
<BR><FONT SIZE=3D2>result or a structure constructor, rather than an =
array constructor,</FONT>
<BR><FONT SIZE=3D2>it is clear that the object should be finalized =
after that PRINT</FONT>
<BR><FONT SIZE=3D2>statement.</FONT>
</P>

<P><FONT SIZE=3D2>However, for array constructors, this does not appear =
to be the case.</FONT>
<BR><FONT SIZE=3D2>In the main program above, should the entity created =
by the array</FONT>
<BR><FONT SIZE=3D2>constructor be finalized after execution of the =
PRINT statement?</FONT>
</P>

<P><FONT SIZE=3D2>ANSWER:</FONT>
</P>

<P><FONT SIZE=3D2>Yes, the array constructor should be finalized.&nbsp; =
Edits are provided to</FONT>
<BR><FONT SIZE=3D2>correct this oversight.</FONT>
</P>

<P><FONT SIZE=3D2>EDITS:</FONT>
</P>

<P><FONT SIZE=3D2>This edit refers to 04-007.</FONT>
</P>

<P><FONT SIZE=3D2>[59:27]&nbsp; After the first occurrence of =
&quot;structure constructor&quot;, insert</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&quot;or array constructor&quot;.&nbsp; On the same line, delete the =
second</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
occurrence of &quot;structure&quot;.</FONT>
</P>

<P><FONT SIZE=3D2>This edit refers to the edit introduced by =
interpretation F03/0007.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
After the first occurrence of &quot;structure constructor&quot;, =
insert</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&quot;or array constructor&quot;. In the same sentence, delete the =
second</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
occurrence of &quot;structure&quot;.</FONT>
</P>

<P><FONT SIZE=3D2>SUBMITTED BY: Rob James</FONT>
</P>

<P><FONT SIZE=3D2>HISTORY: 05-177&nbsp;&nbsp;&nbsp; m172&nbsp; F03/0062 =
Submitted</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
05-224&nbsp;&nbsp;&nbsp; m173&nbsp; Passed by J3 meeting</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
06-133&nbsp;&nbsp;&nbsp; m175&nbsp; Passed J3 letter ballot #12</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
N1658&nbsp;&nbsp;&nbsp;&nbsp; m176&nbsp; Passed WG5 ballot N1657 - fix =
edits</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
N1663&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Reaffirmed in WG5 ballot N1661 on N1660</FONT>
</P>

<P><FONT =
SIZE=3D2>---------------------------------------------------------------=
-------</FONT>
</P>

<P><FONT SIZE=3D2>NUMBER: F03/0066</FONT>
<BR><FONT SIZE=3D2>TITLE: Precision of operation</FONT>
<BR><FONT SIZE=3D2>KEYWORDS: precision, operation</FONT>
<BR><FONT SIZE=3D2>DEFECT TYPE: Interpretation</FONT>
<BR><FONT SIZE=3D2>STATUS: Passed by WG5 ballot</FONT>
</P>

<P><FONT SIZE=3D2>QUESTION:</FONT>
</P>

<P><FONT SIZE=3D2>Given</FONT>
<BR><FONT SIZE=3D2>&nbsp; REAL X</FONT>
<BR><FONT SIZE=3D2>&nbsp; X =3D ... some value ...</FONT>
<BR><FONT SIZE=3D2>&nbsp; IF( (X+3.0) .EQ. 3.0 )...&nbsp; </FONT>
<BR><FONT SIZE=3D2>may the X+3.0 be computed with more range and/or =
precision than that</FONT>
<BR><FONT SIZE=3D2>of REAL?&nbsp; In other words, is PRECISION(X) .EQ. =
PRECISION(X+3.0) always</FONT>
<BR><FONT SIZE=3D2>true; or is PRECISION(X) .LT. PRECISION(X+3.0) =
sometimes true?</FONT>
</P>

<P><FONT SIZE=3D2>References are to J3/04-007.</FONT>
</P>

<P><FONT SIZE=3D2>2.4.1.1 Intrinsic type has &quot;The kind type =
parameter indicates ... the</FONT>
<BR><FONT SIZE=3D2>decimal precision and exponent range for the real =
and complex types,</FONT>
<BR><FONT SIZE=3D2>...&quot;</FONT>
</P>

<P><FONT SIZE=3D2>7.1.4.2 Type, type parameters, and shape of the =
result of an operation</FONT>
<BR><FONT SIZE=3D2>has in (4) &quot;For an expression x1 op x2 where op =
is a numeric intrinsic</FONT>
<BR><FONT SIZE=3D2>binary operator with both operands of the same type =
and kind type</FONT>
<BR><FONT SIZE=3D2>parameters, ..., the kind type parameter of the =
expression is</FONT>
<BR><FONT SIZE=3D2>identical to that of each operand.&quot;</FONT>
</P>

<P><FONT SIZE=3D2>Since X and 3.0 are the same type and have the same =
kind type</FONT>
<BR><FONT SIZE=3D2>parameters, 7.1.4.2 (4) appears to require the X+3.0 =
have just the</FONT>
<BR><FONT SIZE=3D2>range and precision of REAL; no more, no less =
(otherwise, the</FONT>
<BR><FONT SIZE=3D2>precision is not identical).&nbsp; But, several =
members of the J3 email</FONT>
<BR><FONT SIZE=3D2>list have said that the &quot;+&quot; may be done =
with more precision; using</FONT>
<BR><FONT SIZE=3D2>either 1.4(6) or 7.1.8.3 as the reason.</FONT>
</P>

<P><FONT SIZE=3D2>Perhaps something alone the lines of &quot;The values =
of floating operands</FONT>
<BR><FONT SIZE=3D2>and of the results of floating expressions may be =
represented in</FONT>
<BR><FONT SIZE=3D2>greater precision and range than that required by =
the kind type</FONT>
<BR><FONT SIZE=3D2>parameter; the kind type parameter is not changed =
thereby.&quot; should be</FONT>
<BR><FONT SIZE=3D2>added to 7.1.4.2(4).</FONT>
</P>

<P><FONT SIZE=3D2>QUESTION:</FONT>
</P>

<P><FONT SIZE=3D2>Is PRECISION(X) .EQ. PRECISION(X+3.0) always true? =
</FONT>
</P>

<P><FONT SIZE=3D2>ANSWER:</FONT>
</P>

<P><FONT SIZE=3D2>Yes, that is the definition of PRECISION.&nbsp; The =
PRECISION intrinsic has</FONT>
<BR><FONT SIZE=3D2>nothing to do with the precision in which the =
computation X+3.0 is</FONT>
<BR><FONT SIZE=3D2>computed.&nbsp; 7.1.4.2 (4) only describes the =
precision of the end result</FONT>
<BR><FONT SIZE=3D2>of the computation.</FONT>
</P>

<P><FONT SIZE=3D2>The weasel words in 1.4 (6) allow the processor to =
compute this expression</FONT>
<BR><FONT SIZE=3D2>in higher precision than REAL.</FONT>
</P>

<P><FONT SIZE=3D2>EDITS:</FONT>
</P>

<P><FONT SIZE=3D2>None</FONT>
</P>

<P><FONT SIZE=3D2>SUBMITTED BY: Fred Tydeman</FONT>
</P>

<P><FONT SIZE=3D2>HISTORY: 05-193&nbsp;&nbsp;&nbsp; m173&nbsp; F03/0066 =
Submitted</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
05-193r1&nbsp; m173&nbsp; Passed by J3 meeting</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
06-133&nbsp;&nbsp;&nbsp; m175&nbsp; Passed J3 letter ballot #12</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
N1658&nbsp;&nbsp;&nbsp;&nbsp; m176&nbsp; Passed WG5 ballot N1657</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
N1663&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Reaffirmed in WG5 ballot N1661 on N1660</FONT>
</P>

<P><FONT =
SIZE=3D2>---------------------------------------------------------------=
-------</FONT>
</P>

<P><FONT SIZE=3D2>NUMBER: F03/0067</FONT>
<BR><FONT SIZE=3D2>TITLE: Accuracy of conversion of real literal =
constants</FONT>
<BR><FONT SIZE=3D2>KEYWORDS: conversion, accuracy</FONT>
<BR><FONT SIZE=3D2>DEFECT TYPE: Interpretation</FONT>
<BR><FONT SIZE=3D2>STATUS: Passed by WG5 ballot</FONT>
</P>

<P><FONT SIZE=3D2>QUESTION:</FONT>
</P>

<P><FONT SIZE=3D2>The following is independent of IEEE-754.</FONT>
</P>

<P><FONT SIZE=3D2>Fortran 2003 10.6.1.2.6 covers conversions between =
&quot;decimal values&quot;</FONT>
<BR><FONT SIZE=3D2>and &quot;internal values&quot; and has some strong =
requirements.</FONT>
</P>

<P><FONT SIZE=3D2>Are there equivalent requirements on accuracy for =
conversions of real</FONT>
<BR><FONT SIZE=3D2>literal constants?&nbsp; Sections 4.1.2 and 4.4.2 =
seems like the places to</FONT>
<BR><FONT SIZE=3D2>find them (if they exist).</FONT>
</P>

<P><FONT SIZE=3D2>What rounding mode is used for conversions of real =
literal constants?</FONT>
<BR><FONT SIZE=3D2>Is the same rounding mode used for all such =
conversions?</FONT>
</P>

<P><FONT SIZE=3D2>The following four questions are about positive =
values, but the same</FONT>
<BR><FONT SIZE=3D2>would apply to negative values.</FONT>
</P>

<P><FONT SIZE=3D2>Must all &quot;decimal values&quot; in the range =
smallest non-zero finite</FONT>
<BR><FONT SIZE=3D2>internal value (which could be a denormal) to =
largest finite internal</FONT>
<BR><FONT SIZE=3D2>value, e.g. 0.1, be converted?</FONT>
</P>

<P><FONT SIZE=3D2>Must all &quot;decimal values&quot; in the range zero =
to smallest non-zero</FONT>
<BR><FONT SIZE=3D2>finite internal value, e.g. 1.0e-999999999, be =
converted?</FONT>
</P>

<P><FONT SIZE=3D2>Must all &quot;decimal values&quot; larger than the =
largest finite internal</FONT>
<BR><FONT SIZE=3D2>value, e.g. 9.9e+99999999999, be converted if =
infinity is an internal</FONT>
<BR><FONT SIZE=3D2>value?&nbsp; What does nearest rounding mean for =
these cases?</FONT>
</P>

<P><FONT SIZE=3D2>What requirements exist for &quot;decimal values&quot;=
 larger than the largest</FONT>
<BR><FONT SIZE=3D2>finite internal value if infinity is not an internal =
value?</FONT>
</P>

<P><FONT SIZE=3D2>ANSWER:</FONT>
</P>

<P><FONT SIZE=3D2>There are no requirements on accuracy for conversions =
of real literal</FONT>
<BR><FONT SIZE=3D2>constants.</FONT>
</P>

<P><FONT SIZE=3D2>The standard does not specify the rounding mode used =
for conversions</FONT>
<BR><FONT SIZE=3D2>of real literal constants, nor does it require the =
same rounding mode</FONT>
<BR><FONT SIZE=3D2>to be used for all conversions.</FONT>
</P>

<P><FONT SIZE=3D2>Whether all decimal values in any range can be =
converted is not</FONT>
<BR><FONT SIZE=3D2>standardized.</FONT>
</P>

<P><FONT SIZE=3D2>There are no requirements for &quot;decimal =
values&quot; larger than the largest</FONT>
<BR><FONT SIZE=3D2>finite internal value whether infinity is an =
internal value or not.</FONT>
</P>

<P><FONT SIZE=3D2>EDITS:</FONT>
</P>

<P><FONT SIZE=3D2>None</FONT>
</P>

<P><FONT SIZE=3D2>SUBMITTED BY: Fred Tydeman</FONT>
</P>

<P><FONT SIZE=3D2>HISTORY: 05-206&nbsp;&nbsp;&nbsp; m173&nbsp; F03/0067 =
Submitted</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<FONT SIZE=3D2> =
05-206r1&nbsp; m173&nbsp; Passed by J3 meeting</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
06-133&nbsp;&nbsp;&nbsp; m175&nbsp; Passed J3 letter ballot #12</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
N1658&nbsp;&nbsp;&nbsp;&nbsp; m176&nbsp; Passed WG5 ballot N1657</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
N1663&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Reaffirmed in WG5 ballot N1661 on N1660</FONT>
</P>

<P><FONT =
SIZE=3D2>---------------------------------------------------------------=
-------</FONT>
</P>

<P><FONT SIZE=3D2>NUMBER: F03/0068</FONT>
<BR><FONT SIZE=3D2>TITLE: First character of namelist output =
records</FONT>
<BR><FONT SIZE=3D2>KEYWORDS: namelist, output, UDDTIO</FONT>
<BR><FONT SIZE=3D2>DEFECT TYPE: Erratum</FONT>
<BR><FONT SIZE=3D2>STATUS: Passed by WG5 ballot</FONT>
</P>

<P><FONT SIZE=3D2>QUESTION:</FONT>
</P>

<P><FONT SIZE=3D2>The last sentence of 10.10.2.2 of Fortran 2003 =
states:</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; Except for continuation of =
delimited character sequences, each</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; output record begins with a blank =
character.</FONT>
</P>

<P><FONT SIZE=3D2>If a namelist output statement causes a user-defined =
derived-type</FONT>
<BR><FONT SIZE=3D2>output procedure to be called, was it intended to be =
standard-</FONT>
<BR><FONT SIZE=3D2>conforming for that procedure to create a new record =
(perhaps by using</FONT>
<BR><FONT SIZE=3D2>the slash edit descriptor) that does not begin with =
a blank character?</FONT>
</P>

<P><FONT SIZE=3D2>ANSWER:</FONT>
</P>

<P><FONT SIZE=3D2>Yes, this situation was intended to be =
standard-conforming.&nbsp; Explicit formatting</FONT>
<BR><FONT SIZE=3D2>in user-defined derived-type output is not required =
to output a leading blank</FONT>
<BR><FONT SIZE=3D2>in this case.&nbsp; An edit is provided to correct =
this oversight.</FONT>
</P>

<P><FONT SIZE=3D2>EDITS:</FONT>
</P>

<P><FONT SIZE=3D2>All edits refer to 04-007.</FONT>
</P>

<P><FONT SIZE=3D2>[247:33] Before &quot;continuation&quot;, insert =
&quot;new records created by</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
explicit formatting within a user-defined derived-type</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
output procedure or by&quot;.</FONT>
</P>

<P><FONT SIZE=3D2>SUBMITTED BY: Rob James</FONT>
</P>

<P><FONT SIZE=3D2>HISTORY: 05-227&nbsp;&nbsp;&nbsp; m173&nbsp; F03/0068 =
Submitted</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
05-227r1&nbsp; m173&nbsp; Passed by J3 meeting</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
06-133&nbsp;&nbsp;&nbsp; m175&nbsp; Passed J3 letter ballot #12</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
N1658&nbsp;&nbsp;&nbsp;&nbsp; m176&nbsp; Passed WG5 ballot N1657</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
N1663&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Reaffirmed in WG5 ballot N1661 on N1660</FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT =
SIZE=3D2>---------------------------------------------------------------=
-------</FONT>
</P>

<P><FONT SIZE=3D2>NUMBER: F03/0069</FONT>
<BR><FONT SIZE=3D2>TITLE: Procedure pointers in defined =
assignment</FONT>
<BR><FONT SIZE=3D2>KEYWORDS: procedure pointer, defined =
assignment</FONT>
<BR><FONT SIZE=3D2>DEFECT TYPE: Erratum</FONT>
<BR><FONT SIZE=3D2>STATUS: Passed by WG5 ballot</FONT>
</P>

<P><FONT SIZE=3D2>QUESTION:</FONT>
</P>

<P><FONT SIZE=3D2>In 12.3.2.1.1 of Fortran 2003, at [262:8-9], the =
following is stated</FONT>
<BR><FONT SIZE=3D2>about the dummy arguments of a function that defines =
an operation:</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; The dummy arguments shall be =
nonoptional dummy data objects and</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; shall be specified with INTENT =
(IN).</FONT>
</P>

<P><FONT SIZE=3D2>This clearly states that a dummy argument of such a =
function cannot be</FONT>
<BR><FONT SIZE=3D2>a procedure pointer.&nbsp; The same is not stated =
for the dummy arguments</FONT>
<BR><FONT SIZE=3D2>of a subroutine that defines assignment.</FONT>
</P>

<P><FONT SIZE=3D2>Was it intended that procedure pointers should be =
allowed in defined</FONT>
<BR><FONT SIZE=3D2>assignment, but not in defined operations?</FONT>
</P>

<P><FONT SIZE=3D2>ANSWER:</FONT>
</P>

<P><FONT SIZE=3D2>No.&nbsp; It was not intended that procedure pointers =
should be allowed in</FONT>
<BR><FONT SIZE=3D2>either defined assignment or defined =
operations.&nbsp; An edit is provided</FONT>
<BR><FONT SIZE=3D2>to correct this oversight.</FONT>
</P>

<P><FONT SIZE=3D2>EDITS:</FONT>
</P>

<P><FONT SIZE=3D2>All edits refer to 04-007.</FONT>
</P>

<P><FONT SIZE=3D2>[263:6]&nbsp; Replace &quot;Each argument shall be =
nonoptional.&quot; with</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&quot;The dummy arguments shall be nonoptional dummy data =
objects.&quot;</FONT>
</P>

<P><FONT SIZE=3D2>SUBMITTED BY: Rob James</FONT>
</P>

<P><FONT SIZE=3D2>HISTORY: 05-228&nbsp;&nbsp;&nbsp; m173&nbsp; F03/0069 =
Passed by J3 meeting</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
06-133&nbsp;&nbsp;&nbsp; m175&nbsp; Passed J3 letter ballot #12</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
N1658&nbsp;&nbsp;&nbsp;&nbsp; m176&nbsp; Passed WG5 ballot N1657</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
N1663&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Reaffirmed in WG5 ballot N1661 on N1660</FONT>
</P>

<P><FONT =
SIZE=3D2>---------------------------------------------------------------=
-------</FONT>
</P>

<P><FONT SIZE=3D2>NUMBER: F03/0070</FONT>
<BR><FONT SIZE=3D2>TITLE: Can child I/O statements be advancing I/O =
statements?</FONT>
<BR><FONT SIZE=3D2>KEYWORDS: UDDTIO, ADVANCE=3D</FONT>
<BR><FONT SIZE=3D2>DEFECT TYPE: Erratum</FONT>
<BR><FONT SIZE=3D2>STATUS: Passed by WG5 ballot</FONT>
</P>

<P><FONT SIZE=3D2>[175:30-31] of Fortran 2003 states:</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; An advancing input/output =
statement always positions a record file</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; after the last record read or =
written, unless there is an error</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; condition.</FONT>
</P>

<P><FONT SIZE=3D2>Since a child I/O statement does not position a file =
after the last</FONT>
<BR><FONT SIZE=3D2>Record [194:19][199:8-9], this implies that a child =
I/O statement cannot </FONT>
<BR><FONT SIZE=3D2>be an advancing I/O statement.</FONT>
</P>

<P><FONT SIZE=3D2>[189:6-9] of Fortran 2003 states:</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; The ADVANCE=3D specifier =
determines whether advancing input/output</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; occurs for this input/output =
statement. If YES is specified,</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; advancing input/output occurs. If =
NO is specified, nonadvancing</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; input/output occurs (9.2.3.1). If =
this specifier is omitted from</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; an input/output statement that =
allows the specifier, the default</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; value is YES.</FONT>
</P>

<P><FONT SIZE=3D2>This clearly states that any data transfer statement =
is an advancing</FONT>
<BR><FONT SIZE=3D2>I/O statement if the value 'NO' is not specified for =
the ADVANCE=3D</FONT>
<BR><FONT SIZE=3D2>specifier.</FONT>
</P>

<P><FONT SIZE=3D2>These two statements seem to contradict each other. =
</FONT>
</P>

<P><FONT SIZE=3D2>QUESTION:</FONT>
</P>

<P><FONT SIZE=3D2>If a child I/O statement does not have an ADVANCE=3D =
specifier with the</FONT>
<BR><FONT SIZE=3D2>value 'NO', is it an advancing I/O statement?</FONT>
</P>

<P><FONT SIZE=3D2>DISCUSSION:</FONT>
</P>

<P><FONT SIZE=3D2>The answer to this question affects the value for the =
IOSTAT variable</FONT>
<BR><FONT SIZE=3D2>for child READ statements in some situations.&nbsp; =
For example, in the</FONT>
<BR><FONT SIZE=3D2>following program, the value of &quot;stat1&quot; =
should be equal to IOSTAT_EOF</FONT>
<BR><FONT SIZE=3D2>if the child READ statement is advancing, but it =
should be equal to</FONT>
<BR><FONT SIZE=3D2>IOSTAT_EOR if the statement is nonadvancing.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MODULE m</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; TYPE =
t</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
CHARACTER(2) :: x(2)</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
CONTAINS</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
PROCEDURE :: readT</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; GENERIC =
:: READ(FORMATTED) =3D&gt; readT</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; END =
TYPE</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CONTAINS</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
SUBROUTINE readT(dtv, unit, iotype, v_list, iostat, iomsg)</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
CLASS(t), INTENT(INOUT) :: dtv</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
INTEGER, INTENT(IN) :: unit</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
CHARACTER(*), INTENT(IN) :: iotype</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
INTEGER, INTENT(IN)&nbsp; :: v_list(:)</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
INTEGER, INTENT(OUT) :: iostat</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
CHARACTER(*), INTENT(INOUT) :: iomsg</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; READ =
(unit, '(2a2)', IOSTAT=3Diostat) dtv%x</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; END =
SUBROUTINE</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; END MODULE</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; PROGRAM p</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; USE =
m</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; USE, =
INTRINSIC :: ISO_FORTRAN_ENV</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; TYPE(t) =
t1</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
CHARACTER(3) :: c =3D '123'</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; INTEGER =
stat1</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; READ (c, =
*, IOSTAT=3Dstat1) t1</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; PRINT *, =
(stat1 =3D=3D IOSTAT_EOR), (stat1 =3D=3D IOSTAT_EOF)</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; END PROGRAM</FONT>
</P>

<P><FONT SIZE=3D2>ANSWER:</FONT>
</P>

<P><FONT SIZE=3D2>No, such a child I/O statement is not =
advancing.&nbsp; Edits are provided</FONT>
<BR><FONT SIZE=3D2>to correct this inconsistency.</FONT>
</P>

<P><FONT SIZE=3D2>EDITS:</FONT>
</P>

<P><FONT SIZE=3D2>All edits refer to 04-007.</FONT>
</P>

<P><FONT SIZE=3D2>[189:7]&nbsp; Replace &quot;this input/output =
statement&quot; by &quot;a nonchild</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
input/output statement&quot;.</FONT>
</P>

<P><FONT SIZE=3D2>[189:9]&nbsp; Replace &quot;from an input/output =
statement&quot; by &quot;from a</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
nonchild input/output statement&quot;.</FONT>
</P>

<P><FONT SIZE=3D2>[189:9]&nbsp; After &quot;YES.&quot; Insert</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&quot;&nbsp; A formatted child input/output statement is a</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
nonadvancing input/output statement, and any ADVANCE=3D</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
specifier is ignored.&quot;</FONT>
</P>

<P><FONT SIZE=3D2>[199:8+] Add a new bullet:</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&quot; o Any ADVANCE=3D specifier in a child input/output statement =
is</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp; ignored.&quot;</FONT>
</P>

<P><FONT SIZE=3D2>SUBMITTED BY: Rob James</FONT>
</P>

<P><FONT SIZE=3D2>HISTORY: 05-229&nbsp;&nbsp;&nbsp; m173&nbsp; F03/0070 =
Submitted</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
05-229r1&nbsp; m173&nbsp; Passed by J3 meeting</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
06-133&nbsp;&nbsp;&nbsp; m175&nbsp; Passed J3 letter ballot #12 - typos =
fixed</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
N1658&nbsp;&nbsp;&nbsp;&nbsp; m176&nbsp; Passed WG5 ballot N1657 - fix =
edits</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
N1663&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Reaffirmed in WG5 ballot N1661 on N1660</FONT>
</P>

<P><FONT =
SIZE=3D2>---------------------------------------------------------------=
-------</FONT>
</P>

<P><FONT SIZE=3D2>NUMBER: F03/0072</FONT>
<BR><FONT SIZE=3D2>TITLE: Default initialization for =
&quot;automatic&quot; components</FONT>
<BR><FONT SIZE=3D2>KEYWORDS: Parameterized Derived Type, Default =
Initialization</FONT>
<BR><FONT SIZE=3D2>DEFECT TYPE: Erratum</FONT>
<BR><FONT SIZE=3D2>STATUS: Passed by WG5 ballot</FONT>
</P>

<P><FONT SIZE=3D2>QUESTION:</FONT>
</P>

<P><FONT SIZE=3D2>Consider</FONT>
<BR><FONT SIZE=3D2>&nbsp; TYPE t(len)</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; INTEGER,LEN :: len</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; CHARACTER(len) :: cvalue =3D =
&quot;xyz&quot;</FONT>
<BR><FONT SIZE=3D2>&nbsp; END TYPE</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp; SUBROUTINE s(n)</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; TYPE(t(n)) x</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; ...</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp; TYPE t2(len2)</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; TYPE(t(len2)) :: tvalue =3D =
t(10,&quot;fred nurke&quot;)</FONT>
<BR><FONT SIZE=3D2>&nbsp; END TYPE</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp; SUBROUTINE s2(n)</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; TYPE(t2(n)) :: y</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; ...</FONT>
</P>

<P><FONT SIZE=3D2>The type definition for T appears to conform to the =
standard; it</FONT>
<BR><FONT SIZE=3D2>allows an &quot;automatic&quot; component to be =
default initialized.&nbsp; However,</FONT>
<BR><FONT SIZE=3D2>the declaration of the local variable X in =
subroutine S will</FONT>
<BR><FONT SIZE=3D2>initialize the component differently depending on =
the value of N, for</FONT>
<BR><FONT SIZE=3D2>example, giving the CVALUE component the value =
&quot;&quot;, &quot;x&quot;, &quot;xy&quot;, &quot;xyz&quot;,</FONT>
<BR><FONT SIZE=3D2>&quot;xyz &quot; for N being 0, 1, 2, 3, 4 =
respectively.</FONT>
</P>

<P><FONT SIZE=3D2>Q1. Was it intended that &quot;automatic&quot; =
components can be</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; default-initialized?</FONT>
</P>

<P><FONT SIZE=3D2>If the answer is &quot;Yes&quot;, the type definition =
for T2 also appears to</FONT>
<BR><FONT SIZE=3D2>conform to the standard.&nbsp; However, the =
declaration of Y in S2 will not</FONT>
<BR><FONT SIZE=3D2>work if N has any value other than 10 at run =
time.&nbsp; This is</FONT>
<BR><FONT SIZE=3D2>surprising;&nbsp; there appears to be no other =
situation where the runtime</FONT>
<BR><FONT SIZE=3D2>value of a length type parameter can render a =
declaration invalid.</FONT>
</P>

<P><FONT SIZE=3D2>Q2. Is this situation intentional?</FONT>
</P>

<P><FONT SIZE=3D2>ANSWER:</FONT>
</P>

<P><FONT SIZE=3D2>Q1. No, this was not intended.&nbsp; An edit is =
supplied to fix this.</FONT>
</P>

<P><FONT SIZE=3D2>Q2. Not applicable.</FONT>
</P>

<P><FONT SIZE=3D2>EDITS:</FONT>
</P>

<P><FONT SIZE=3D2>In 4.5.3 Components, immediately before R445</FONT>
<BR><FONT SIZE=3D2>&lt;proc-component-def-stmt&gt;, insert a new =
constraint: [50:40+]</FONT>
<BR><FONT SIZE=3D2>&quot;C447a (R440) If =
&lt;component-initialization&gt; appears, every type</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; parameter and array bound of the component shall be =
an</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; initialization expression.&quot;</FONT>
</P>

<P><FONT SIZE=3D2>SUBMITTED BY: Malcolm Cohen</FONT>
</P>

<P><FONT SIZE=3D2>HISTORY: 05-285&nbsp;&nbsp;&nbsp; m174&nbsp; F03/0072 =
Submitted</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<FONT SIZE=3D2> =
05-285r1&nbsp; m174&nbsp; Revised edit</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
06-133&nbsp;&nbsp;&nbsp; m175&nbsp; Passed J3 letter ballot #12</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
N1658&nbsp;&nbsp;&nbsp;&nbsp; m176&nbsp; Passed WG5 ballot N1657</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
N1663&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Reaffirmed in WG5 ballot N1661 on N1660</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Sally Seitz</FONT>
<BR><FONT SIZE=3D2>Program Manager</FONT>
<BR><FONT SIZE=3D2>American National Standards Institute</FONT>
<BR><FONT SIZE=3D2>25 West 43rd Street, 4th Floor</FONT>
<BR><FONT SIZE=3D2>New York, NY 10036</FONT>
<BR><FONT SIZE=3D2>Tel: 212 642 4918</FONT>
<BR><FONT SIZE=3D2>Fax: 212 840 2298</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C6AA73.CC113FA2--