(j3.2006) (SC22WG5.4834) WG5 letter ballot 5 on Fortran 2008 interpretations

John Reid John.Reid
Mon Nov 12 04:01:07 EST 2012


WG5,

Here is WG5 letter ballot 5 on Fortran 2008 interpretations. It has the 
deadline of 0900 UK time on Monday, 10 December 2012.

Cheers,

John.
-------------- next part --------------
                                             ISO/IEC JTC1/SC22/WG5 N1949

          WG5 letter ballot 5 on Fortran 2008 interpretations
                      John Reid, 11 November 2012

This is the fifth WG5 vote on a set of draft interpretations for Fortran 
2008. They have all been approved in a J3 letter ballot.  

The rules we operate on say:
--- ---
4. The chair of J3/interp gathers all interp answers that are marked
   "passed by J3 letter ballot" and forwards them to the WG5 convenor.
   The WG5 convenor holds a ballot of individual members; a no vote
   must be accompanied by an explanation of the changes necessary to
   change the member's vote to yes. The answers that pass this ballot
   become "WG5 approved".

   J3/interp reserves the right to recall an interp answer for more
   study even if the answer passes.

5. "WG5 approved" answers are processed into a corrigendum document by
   taking the edits from the interp answers and putting them in the
   format required by ISO.  A WG5 vote is made on forwarding the
   corrigendum to SC22.

The following Fortran 2008 interpretations are being balloted:

Yes  No   Number     Title

---  ---  F08/0040   MOVE_ALLOC for coarrays
---  ---  F08/0074   Implicit type in BLOCK construct
---  ---  F08/0077   Function references as variables in DATA statements
---  ---  F08/0078   Are the IEEE values +0 and -0 distinguished
---  ---  F08/0079   NAMELIST and type specification
---  ---  F08/0080   Array constructors with polymorphic values
---  ---  F08/0081   Deallocation error handling
---  ---  F08/0082   Generic identifier and dtv arguments

The text of these interpretations is attached.  Each interpretation
starts with a row of "-"s.

Please mark the above -Y- in the Yes column for "yes", -C- in the Yes
column for "yes with comment", or -N- in the No column for a "no"
answer {be sure to include your reasons with "no"} and send to

        sc22wg5 at open-std.org

by 0900 UK time on Monday, 10 December 2012, in order to be counted.

Thanks,

John.                         


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


NUMBER: F08/0040
TITLE:  MOVE_ALLOC for coarrays
KEYWORDS: intrinsic, allocation
DEFECT TYPE: Erratum
STATUS: Passed by J3 letter ballot

QUESTION:

Was it intended that MOVE_ALLOC be applicable to coarrays?

ANSWER:

Yes.  A call to MOVE_ALLOC on coarrays might involve the deallocation
of a coarray, therefore MOVE_ALLOC needs to be an image control
statement.

Also, the coranks of FROM and TO need to be the same.

Edits are supplied to correct this.

DISCUSSION:

It might appear that C541 which says
  "An entity with the INTENT(OUT) attribute shall not be an
   allocatable coarray ..."
might prohibit MOVE_ALLOC from operating on coarrays; however, this
constraint applies to user-defined procedure not to intrinsic
procedures.

An edit is supplied to clarify C541.

EDITS to 10-007r1:

[97:13] In 5.3.10 INTENT attribute, C541,
  Change "An entity"
  to "A dummy argument of a nonintrinsic procedure".
{Clarify the constraint.}

[188:23+] In 8.5.1 Image control statements, paragraph 2,
          insert new bullet point before the STOP statement one,
  "- a CALL statement that invokes the intrinsic subroutine MOVE_ALLOC
     with coarray arguments;"

[372;18] In 13.7.118p3 MOVE_ALLOC, FROM argument,
         "type and rank" -> "type, rank, and corank".
{Edit is not necessary, but makes it more readable.}

[372:19] In 13.7.118p3 MOVE_ALLOC, TO argument,
         After "same rank" insert "and corank".

[372:29+] 13.7.118, p6+
  Insert new paragraph immediately before "Example:"
    "When a reference to MOVE_ALLOC is executed for which the FROM
     argument is a coarray, there is an implicit synchronization of
     all images.  On each image, execution of the segment (8.5.2)
     following the CALL statement is delayed until all other images
     have executed the same statement the same number of times."

SUBMITTED BY: John Reid

HISTORY: 10-200    m193  F08/0040 submitted
         10-200r1  m193  Answer edited - Passed by J3 meeting
         11-129    m194  Passed as amended by J3 letter ballot
                          #22 10-254
         11-006Ar1 m196  Adjust edits to reference 10-007r1
         N1889     m197  Failed WG5 ballot 2 N1877
         12-139    m197  Revised answer - passed J3 meeting
         12-165r2  m198  Failed J3 letter ballot #25 12-147
         12-168    m198  Revised edits, added discussion section.
         12-168r1  m198  Fixed typo - passed J3 meeting
         12-196    m199  Passed as amended by J3 letter ballot
                          #26, 12-184

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

NUMBER: F08/0074
TITLE: Implicit type in BLOCK construct
KEYWORDS: IMPLICIT, BLOCK
DEFECT TYPE: Erratum
STATUS: Passed by J3 letter ballot

QUESTION:

Consider

  Program m198_1
    Implicit Complex(a-z)
    Logical x
    x = .True.
    Block
      Dimension x(2)
      x = 3
      Print *,x
    End Block
  End Program

Is this standard-conforming, and if so, what is the type of the X
inside the BLOCK construct?

The Fortran 2008 standard specifies the implicit mapping in program
units, interface bodies, internal procedures, and module procedures,
at 5.5p3, but does not specify the implicit mapping in a BLOCK
construct.

ANSWER:

This was intended to be standard-conforming; the type of X is COMPLEX.
An edit is provided to remedy this omission.

EDIT:

[109:16] In 5.5p3, last sentence,
         After "and the default for"
         change "an internal or module procedure"
         to "a BLOCK construct, internal subprogram, or module
         subprogram".

This makes the whole sentence read
  "If a mapping is not specified for a letter, the default for a
   program unit or an interface body is default integer if the letter
   is I, J, ..., or N and default real otherwise, and the default for
   a BLOCK construct, internal subprogram, or module subprogram, is
   the mapping in the host scoping unit."

SUBMITTED BY: Malcolm Cohen

HISTORY: 12-151    m198  F08/0074 submitted.
         12-151r1  m198  Revised edit.
         12-151r2  m198  Clarified answer, passed J3 meeting.
         12-196    m199  Passed by J3 letter ballot #26, 12-184

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

NUMBER: F08/0077
TITLE: Function references as variables in DATA statements
KEYWORDS: function, reference, DATA
DEFECT TYPE: Erratum
STATUS: Passed by J3 letter ballot

QUESTION:

The Fortran 2008 standard extended the syntax of variables to
allow references to functions to be variables (6.2, 117:13,15).
Because of that extension, a function reference may appear as a
<data-stmt-object> (5.4.7, 104:15).  For example, the program

      PROGRAM DATA
        REAL, TARGET :: X
        DATA PF()/1.0/
      CONTAINS
        FUNCTION PF()
          REAL, POINTER :: PF
          PF => X
        END FUNCTION
      END

satisfies the syntax rules and constraints of Fortran 2008.
Was this intended?

ANSWER:

References to function were not intended to be allowed as
<data-stmt-object>s.  An edit is supplied to correct this
oversight.

EDIT:

[5.4.7, 104:26-27]

Replace
    "In a <variable> that is a <data-stmt-object>, each
     subscript, section subscript, substring starting point
     and substring ending point shall"
with
    "A <data-stmt-object> that is a <variable> shall be a
     <designator>, not an <expr>.  Each subscript, section
     subscript, substring starting point, and substring
     ending point in the <variable> shall"

SUBMITTED BY: Robert Corbett

HISTORY: 12-153    m198  F08/0077 submitted
         12-153r1  m198  Revised edits, passed J3 meeting
         12-196    m199  Passed J3 letter ballot #26, 12-184

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

NUMBER: F08/0078
TITLE: Are the IEEE values +0 and -0 distinguished
KEYWORDS: IEEE, zero, IEEE_SUPPORT_DATATYPE
DEFECT TYPE: Clarification
STATUS: Passed by J3 letter ballot

QUESTION:

Suppose the value of IEEE_SUPPORT_DATATYPE is true for arguments of
some kind type parameter values for a processor.  Is the processor
required to distinguish between the real values +0 and -0 if the kind
type parameter value of those zeros is among the kind type parameter
values for which IEEE_SUPPORT_DATATYPE is true?

ANSWER:

No, the processor is not required to distinguish between positive and
negative zero.


DISCUSSION:

If IEEE_SUPPORT_DATATYPE is true, IEEE_COPY_SIGN is required to behave
differently with positive and negative zero representations; however
this is because the IEEE_COPY_SIGN function copies the "sign bit" of
the underlying representation, and in this it is acting in the same
manner as the TRANSFER intrinsic.

This means that even on a processor that does not distinguish between
positive and negative zero in the places where the Fortran standard
has different behaviour depending on that distinction (viz I/O and
the SIGN intrinsic), the processor can still provide the IEEE features
and the user can still access the IEEE copysign functionality using
the IEEE_COPY_SIGN function.

EDITS:

None.

SUBMITTED BY: Robert Corbett

HISTORY: 12-154    m198  F08/0078 submitted
         12-154r1  m198  Revised answer, passed J3 meeting
         12-196    m199  Passed by J3 letter ballot #26, 12-184

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

NUMBER: F08/0079
TITLE: NAMELIST and type specification
KEYWORDS: NAMELIST
DEFECT TYPE: Erratum
STATUS: Passed by J3 letter ballot

QUESTION:

Q1.  Consider

  Module m198_002a
    Type t
      Real c
    Contains
      Procedure :: fwrite => fwrite_t
      Generic :: Write(Formatted) => fwrite
    End Type
    Type,Extends(t) :: t2
      Logical ok
    End Type
  Contains
    Subroutine fwrite_t(dtv,unit,iotype,v_list,iostat,iomsg)
      Class(t),Intent(In) :: dtv
      Integer,Intent(In) :: unit,v_list(:)
      Character(*),Intent(In) :: iotype
      Integer,Intent(Out) :: iostat
      Character(*),Intent(InOut) :: iomsg
      If (iotype/='NAMELIST' .And. iotype/='LISTDIRECTED') &
        Stop 'NYI'
      Select Type (dtv)
        Class Is (t)
          Write(unit,*,Iostat=iostat,Iomsg=iomsg) 'T',dtv%c
        Class Is (t2)
          Write(unit,*,Iostat=iostat,Iomsg=iomsg) 'T2',dtv%c,dtv%ok
      End Select
    End Subroutine
  End Module
  Program test
    Use m198_002a
    Class(t),Pointer :: x                ! A
    Namelist/n/x
    Allocate(x,Source=t(1.5))            ! B
    Write (*,n)
    Allocate(x,Source=t2(1.5,.True.))    ! C
    Write (*,n)
  End Program

The standard requires, at 5.6p5,
   "A namelist group object ... shall have its type ... specified
    by previous specification statements ...".

The declared type of X is specified by the type declaration marked
"! A", but the dynamic type of X is specified by one of the assignment
statements (either "! B" or "! C").

Is this program intended to be standard-conforming?


Q2.  Consider

  Module m198_002b
    Use Iso_Fortran_Env
    Type t(p)
      Integer,Kind :: p
      Real(Selected_Real_Kind(p)) c
    Contains
      Procedure :: fwrite => fwrite_t
      Generic :: Write(Formatted) => fwrite
    End Type
    Type,Extends(t) :: t2(k)
      Integer,Kind :: k
      Integer(k) e
    End Type
  Contains
    Subroutine fwrite_t(dtv,unit,iotype,v_list,iostat,iomsg)
      Class(t(6)),Intent(In) :: dtv
      Integer,Intent(In) :: unit,v_list(:)
      Character(*),Intent(In) :: iotype
      Integer,Intent(Out) :: iostat
      Character(*),Intent(InOut) :: iomsg
      If (iotype/='NAMELIST' .And. iotype/='LISTDIRECTED') &
        Stop 'NYI'
      Select Type (dtv)
        Class Is (t(6))
          Write(unit,*,Iostat=iostat,Iomsg=iomsg) 'T',dtv%c
        Class Is (t2(6,int32))
          Write(unit,*,Iostat=iostat,Iomsg=iomsg) 'T2',dtv%c,dtv%e
        Class Is (t2(6,int64))
          Write(unit,*,Iostat=iostat,Iomsg=iomsg) 'T2',dtv%c,dtv%e
      End Select
    End Subroutine
  End Module
  Program test
    Use m198_002b
    Class(t(6)),Pointer :: x                  ! A
    Namelist/n/x
    Allocate(x,Source=t(6)(1.5))              ! B
    Write (*,n)
    Allocate(x,Source=t2(6,int32)(1.5,2**30)) ! C
    Write (*,n)
    Allocate(x,Source=t2(6,int64)(1.5,2**60)) ! D
    Write (*,n)
  End Program

The standard required, at 5.6p5,
  "A namelist group object ... shall have its ... type parameters
   ... specified by previous specification statements ...".
This was modified by Corrigendum 1 to read
  "A namelist group object ... shall have its ... kind type
   parameters ... specified by previous specification statements ...".

The declared type of X has the kind type parameter P, and this is duly
specified at the statement marked "! A", but the dynamic type of X
after either of the assignment statements marked "! C" or "! D" has an
additional kind type parameter K, and this specification does not
precede the NAMELIST statement.

Is this program intended to be standard-conforming?

Q3.  Consider the program consisting of the same module as in Q2, but
     with the revised main program:

  Program test
    Use m198_002b
    Implicit Type(t(6)) (a-z)
    Namelist/n/x
    Class(t(6)),Pointer :: x                  ! A
    Allocate(x,Source=t(6)(1.5))              ! B
    Write (*,n)
    Allocate(x,Source=t2(6,int32)(1.5,2**30)) ! C
    Write (*,n)
    Allocate(x,Source=t2(6,int64)(1.5,2**60)) ! D
    Write (*,n)
  End Program

The standard says at 5.6p5
  "If a namelist group object is typed by the implicit typing rules,
   its appearance in any subsequent type declaration statement shall
   confirm the implied type and type parameters."

The declared type of X, and its declared kind type parameters, are
specified at "! A", and these are indeed the same type and type
parameters that appear in the IMPLICIT statement, but X is CLASS(T(6))
not TYPE(T(6)).

Is this program intended to be standard-conforming?

Q4.  Consider

  Module m198_002d
    Use Iso_Fortran_Env
    Type t(mp)
      Integer,Len :: mp
      Integer c(mp)
    Contains
      Procedure :: fwrite => fwrite_t
      Generic :: Write(Formatted) => fwrite
    End Type
    Type,Extends(t) :: t2(mk)
      Integer,Len :: mk
      Integer e(mk)
    End Type
  Contains
    Subroutine fwrite_t(dtv,unit,iotype,v_list,iostat,iomsg)
      Class(t(*)),Intent(In) :: dtv
      Integer,Intent(In) :: unit,v_list(:)
      Character(*),Intent(In) :: iotype
      Integer,Intent(Out) :: iostat
      Character(*),Intent(InOut) :: iomsg
      If (iotype/='NAMELIST' .And. iotype/='LISTDIRECTED') &
        Stop 'NYI'
      Select Type (dtv)
        Class Is (t(*))
          Write(unit,*,Iostat=iostat,Iomsg=iomsg) 'T',dtv%c
        Class Is (t2(*,*))
          Write(unit,*,Iostat=iostat,Iomsg=iomsg) 'T2',dtv%c,'E',dtv%e
      End Select
    End Subroutine
  End Module
  Program test
    Use m198_002d
    Implicit Type(t(1)) (a-z)
    Namelist/n/x
    Class(t(:)),Pointer :: x                        ! A
    Allocate(x,Source=t(1)([15]))                   ! B
    Write (*,n)
    Allocate(x,Source=t2(2,4)([15,30],[3,2,1,0]))   ! C
    Write (*,n)
    Allocate(x,Source=t2(2,5)([15,30],[4,3,2,1,0])) ! D
    Write (*,n)
  End Program

The declared type of X, and its declared kind type parameters (of
which there are none), are specified at "! A", and these are indeed
the same type and kind type parameters that appear in the IMPLICIT
statement, but the length type parameters are not the same.  However,
after Corrigendum 1 there is no requirement for prior specification of
the length type parameters, so it is unclear whether the requirement
for confirmation is intended to apply to length type parameters as
well as kind type parameters.

Is this program intended to be standard-conforming?

ANSWER:

A1.  This program was intended to be conforming.  The requirement for
     prior specification of the type was intended to mean the declared
     type only.  An edit is supplied to clarify the intent.

A2.  This program was intended to be conforming.  The requirement for
     prior specification of the kind type parameters was intended to
     apply only to type parameters of the declared type.  An edit is
     supplied to clarify the intent.

A3.  This program is conforming.

A4.  This program is not conforming.  If the IMPLICIT statement were
       Implicit Type(t(:)) (a-z)
     it would be conforming.  No edit is necessary.

EDITS:

[111:19-20] In 5.6 paragraph 5,
  Change what was originally
    "type, type parameters, and shape"
  but which was changed by Corrigendum 1 to
    "type, kind type parameters, and rank"
  to
    "declared type, kind type parameters of the declared type, and
     rank".
{It would be nice to be able to say "declared kind type parameters"
 but that phrase it not used in the standard at present.}

SUBMITTED BY: Malcolm Cohen

HISTORY: 12-157    m198  F03/0079 submitted with wrong question.
         12-157r1  m198  Revised question, answer, and edits.
         12-157r2  m198  Revised examples, answer.
         12-157r3  m198  Fixed typos in examples, passed J3 meeting.
         12-196    m199  Passed as amended  by J3 letter ballot
                          #26, 12-184

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

NUMBER: F08/0080
TITLE: Array constructors with polymorphic values
KEYWORDS: Array constructor, polymorphic
DEFECT TYPE: Erratum
STATUS: Passed by J3 letter ballot

QUESTION:

Q1.  Consider

  Program m198_003a
    Type :: t
      Real a
    End Type
    Type,Extends(t) :: t2
      Real b
    End Type
    Class(t),Allocatable :: x,y
    Allocate(x,Source=t2(1,2))
    Allocate(y,Source=t(3))
    Print *, [ t :: x, y ]
  End Program

Constraint C4105 of the standard, page 85, says
  "If <type-spec> specifies a derived type, all <ac-value> expressions
   in the array constructor shall be of that derived type ..."

However, although the declared type of X is type T, its dynamic type
is type T2.

Does this program conform to the standard?

Q2.  Consider

  Program m198_003b
    Type :: t
      Real a
    End Type
    Type,Extends(t) :: t2(n)
      Integer,Len :: n
      Real b(n)
    End Type
    Class(t),Allocatable :: x,y,z
    Allocate(x,Source=t2(3)(1,[2,3,4]))
    Allocate(y,Source=t(5))
    Allocate(z,Source=t2(4)(6,7))
    Print *, [ x, y, z ]
  End Program

4.8 paragraph 2 of the standard says
  "If <type-spec> is omitted, each <ac-value> expression shall have
   the same length type parameters; in this case, the declared type
   and type parameters of the array constructor are those of the
   <ac-value> expressions."

However, although the length type parameters of the declared types of
X, Y and Z are the same (all being the empty set), the length type
parameters of the dynamic types are not: Y has no dynamic length type
parameters, and the value of the dynamic length type parameter N of X
and Z are different.

Does this program conform to the standard?

Q3.  Consider

  Program m198_003c
    Type,Abstract :: t
      Real a
    End Type
    Type,Extends(t) :: t2
      Real b
    End Type
    Class(t),Allocatable :: x,y
    Allocate(x,Source=t2(1,2))
    Allocate(y,Source=t2(3,4))
    Print *, [ x, y ]
  End Program

This appears to conform to the standard, but the dynamic type of the
array constructor is the same as its declared type, and is therefore
abstract.  Is this intended to conform to the standard?

ANSWER:

A1. This program was intended to be conforming.
    An edit is supplied to clarify the standard.

A2. This program was intended to be conforming.
    An edit is supplied to clarify the standard.

A3. This program was not intended to be conforming.
    An edit is supplied to add the necessary requirement to the
    standard.

EDITS:

[85:8-9] In 4.8, C4105,
  Change "all <ac-value> expressions in the <array-constructor> shall
          be of that derived type and"
  to     "the declared type of each <ac-value> expression in the
          <array-constructor> shall be that derived type and".

[85:10+] In 4.8, after C4106, insert new constraint
  "C4106a (R472) The declared type of an <ac-value> shall not be
          abstract."

[85:13-14] In 4.8p2,
  Change "each <ac-value> expression in the array constructor shall
          have the same length type parameters;"
  to     "corresponding length type parameters of the declared type of
          each <ac-value> expression shall have the same value;".

SUBMITTED BY: Malcolm Cohen

HISTORY: 12-159    m198  F03/0080 submitted
         12-159r1  m198  Revised edits.
         12-159r2  m198  Fixed typo, passed J3 meeting.
         12-196    m199  Passed as amended by J3 letter ballot
                          #26, 12-184

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

NUMBER: F08/0081
TITLE: Deallocation error handling
KEYWORDS: FINAL, DEALLOCATE, ALLOCATABLE
DEFECT TYPE: Erratum
STATUS: Passed by J3 letter ballot

QUESTION:

Q1. Consider
  Module m198_005a
    Implicit None
    Type t
      Character(80) :: name = 'Nameless'
    Contains
      Final :: tzap
    End Type
    Private tzap
  Contains
    Subroutine tzap(x)
      Type(t) x
      Print *,'Goodbye ',Trim(x%name)
    End Subroutine
    Subroutine test(p)
      Type(t),Pointer :: p
      Integer istat
      Deallocate(p,Stat=istat)
      If (istat/=0) Print *,'Deallocation error',istat
    End Subroutine
  End Module
  Program testprog
    Use m198_005a
    Type(t),Target :: x
    Type(t),Pointer :: y
    Allocate(y)
    x%name = 'target_x'
    y%name = 'allocated_y'
    Call test(y)
    y => x
    Call test(y)
  End Program

Is this program standard-conforming, and if so, does it print
 Goodbye target_x
?

Note that 4.5.6.3 says
  "When a pointer is deallocated its target is finalized."
This could be interpreted as meaning "successfully deallocated" in
which case the finalizer would not be invoked, or it could be
interpreted as including any unsuccessful deallocation attempt, in
which case the finalizer would be invoked.

Q2. Consider
  Program m198_005b
    Implicit None
    Type t
      Character(:),Allocatable :: name
    End Type
    Type(t),Target :: x
    Type(t),Pointer :: y
    Integer :: istat
    Allocate(y)
    x%name = 'target_x'
    y%name = 'allocated_y'
    Deallocate(y)
    y => x
    Deallocate(y,Stat=istat)
    If (.Not.Allocated(x%name)) Print *,'x is now nameless'
  End Program

6.7.3.2 says
  "When a variable of derived type is deallocated, any allocated
   allocatable subobject is deallocated."

Again, this does not specify whether this applies only to successful
deallocation.

Is this program standard-conforming, and does it print
 x is now nameless
?

ANSWER:

Whether the final subroutine is invoked, and whether any allocated
allocatable subobject is deallocated, is processor dependent.

EDITS:

[76:10] Append new sentence to 4.5.6.3p2 {after F08 corrigendum 1}
  "If an error condition occurs during deallocation, it is processor
   dependent whether finalization occurs."
[131:12] Append new sentence to 6.7.3.2p8
  "If an error condition occurs during deallocation, it is processor
   dependent whether an allocated allocatable subobject is
   deallocated."
[459:33+] In A.2,
  After "whether and when an object is finalized ... (4.5.6.3);"
  Insert new bullet point
    "whether an object is finalized by a deallocation in which an
     error condition occurs (4.5.6.3);"
[460:5+] In A.2,
  After "the order ... event described in 6.7.3.2;"
  Insert new bullet point
    "whether an allocated allocatable subobject is deallocated when
     an error condition occurs in the deallocation of an object
     (6.7.3.2);"

SUBMITTED BY: Malcolm Cohen

HISTORY: 12-160    m198  F03/0081 submitted
         12-160r1  m198  Revised question & answer, passed J3 meeting
         12-196    m199  Passed as amended by J3 letter ballot
                          #26, 12-184

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

NUMBER: F08/0082
TITLE: Generic identifier and dtv arguments
KEYWORDS: Generic, Defined i/o
DEFECT TYPE: Erratum
STATUS: Passed by J3 letter ballot

QUESTION:

Consider
  Module m198_010
    Interface g
      Module Procedure mp1, mp2
    End Interface
    Type t
      Real c
    End Type
    Interface Write(Formatted)
      Module Procedure fwrite
    End Interface
  Contains
    Subroutine mp1(a,dtv)
      Integer,Intent(Out) :: a
      Integer,Intent(In) :: dtv
      a = dtv
    End Subroutine
    Subroutine mp2(b,dtv)
      Real,Intent(Out) :: b
      Integer,Intent(In) :: dtv
    End Subroutine
    Subroutine fwrite(dtv,unit,iotype,v_list,iostat,iomsg)
      Class(t),Intent(In) :: dtv
      Integer,Intent(In) :: unit,v_list(:)
      Character(*),Intent(In) :: iotype
      Integer,Intent(Out) :: iostat
      Character(*),Intent(InOut) :: iomsg
      Write(unit,*,Iostat=iostat,Iomsg=iomsg) 'T',dtv%c
    End Subroutine
  End Module

After corrigendum 1, constraint C1214 reads

  C1214 Within the scope of a <defined-io-generic-spec>, if two
        procedures have the same generic identifier, their \cf{dtv}
        arguments (9.6.4.8.3) shall be distinguishable.

The scope of the WRITE(FORMATTED) generic-spec is the entire module
M198_010, and within that module, the two procedures MP1 and MP2 have
the same identifier (G), but their DTV arguments are not
distinguishable.  This clearly violates the new C1214, but the module
conforms to the Fortran 2003 standard.

Is this module intended to be standard-conforming?

ANSWER:

Yes, this was intended to be standard-conforming.  An edit is supplied
to correct the typographical error in Corrigendum 1.

EDITS:

[286:12-13] In the new version of C1214 from Corrigendum 1,
  change "the same" to "that".

SUBMITTED BY: Malcolm Cohen

HISTORY: 12-169    m198  F03/0082 submitted
         12-169r1  m198  Fixed typo in the example, passed J3 meeting
         12-196    m199  Passed as amended by J3 letter ballot
                          #26, 12-184

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



More information about the J3 mailing list