Subject: N 4082-Defect Report 2 for ISO/IEC 1539-1: 2004, Programming lang uages - Fortran

From: Sally Seitz <[email-masked]>
Date: Tue, 18 Jul 2006 10:09:34 -0400

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

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

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

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

ACTION IDENTIFIER: 
FYI
  
DUE DATE: 
  
DISTRIBUTION: 
TEXT

CROSS REFERENCE: 
  
DISTRIBUTION FORM: 
Def 

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

----------------------------------------------------------------------
   
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 => 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 => 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) == kind(0)
        write (*,*) kind(c%len) == 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 => 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 => 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 => 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 = 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) = 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 => readFormattedT
          GENERIC :: READ(FORMATTED) => 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 = 10
        x%j = 15
        y%i = 20
        y%j = 25
        z%i = 30
        z%j = 35
        i = 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 = 0
        CONTAINS
          PROCEDURE, PRIVATE :: nodeFormattedWrite => writeroutine
          GENERIC :: WRITE(FORMATTED) => nodeFormattedWrite
        END TYPE
      CONTAINS
        SUBROUTINE writeroutine(dtv, unit, iotype, vlist, iostat, iomsg)
          CLASS(node), INTENT(IN) :: dtv
          INTEGER, INTENT(IN) :: unit
          CHARACTER(LEN=*), INTENT(IN) :: iotype
          INTEGER, INTENT(IN) :: vlist(:)
          INTEGER, INTENT(OUT) :: iostat
          CHARACTER(LEN=*), INTENT(INOUT) :: iomsg

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

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

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

 &OUTER
 A= &INNER
 A=4.000000000
 /,  &INNER
 A=4.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 = 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 = 12
        c%j = 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 = 5
        PRINT *, (/ (a, i=1,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 = ... some value ...
  IF( (X+3.0) .EQ. 3.0 )...  
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? 

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

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=
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 
be an advancing I/O statement.

[189:6-9] of Fortran 2003 states:
    The ADVANCE= 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=
specifier.

These two statements seem to contradict each other. 

QUESTION:

If a child I/O statement does not have an ADVANCE= 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) => 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=iostat) dtv%x
        END SUBROUTINE
      END MODULE

      PROGRAM p
        USE m
        USE, INTRINSIC :: ISO_FORTRAN_ENV
        TYPE(t) t1
        CHARACTER(3) :: c = '123'
        INTEGER stat1
        READ (c, *, IOSTAT=stat1) t1
        PRINT *, (stat1 == IOSTAT_EOR), (stat1 == 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=
           specifier is ignored."

[199:8+] Add a new bullet:
         " o Any ADVANCE= 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 = "xyz"
  END TYPE

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

  TYPE t2(len2)
    TYPE(t(len2)) :: tvalue = 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