Subject: Re: [SC22WG5.6743] Final review of WG23 Fortran Vulnerabilities document

From: Masayuki Takata <[email-masked]>
Date: Sun, 5 Jul 2026 04:22:45 +0900

Hello Steve,

I assumed that WG23-N1572 was the latest draft, resulted from the DIS
ballot, i.e. comments
from the NBs and ISO editor(s).   It would be the only sound understanding.
  But, in 7.3.1,
for example, itemization has been done without any comment requiring it.
 (And, it was done
wrongly.  See at the bottom.)

For now, I would stick to the original assumption, and the paragraph/line
counts in the following
are based on the WG23-N1572, hiding changes.   Here, a list item is counted
as a paragraph.

---------------------------------------------
All JP comments except for the following have been satisfactorily resolved:

JP-101 (2nd half), Introduction, paragraph 1, lines 3-4:
Change “This guidance” to “This document”.  --- Accepted.
[Overlooked?  Note that the word “guidance” is no longer used in the title.]

JP-044, 5, Table 1, “Number 4” row, “References” column:
Add “6.18 [WXQ] 6.19 [YZS]” after “6.17 [NAI]”, and change “7.1” to “7.2”.
 --- Changed
[Done, but the right bracket after WXQ is missing.]

JP-045 (partly), 6.*.2, list items:
Correct the delimiters of the following list items:
#2&4 of 6.4.2, #4 of 6.57.2.  --- Changed
[Undone, while many others were done.   Original comment: In a list of
avoidance mechanisms,
all but the last items are delimited by a semicolon, and the last one by a
period.
There are some exceptions to this practice.]

JP-057, 6.8.1, paragraph 1, line 1:
Change “24772-1:2024:2019” to “24772-1:2024”.  --- Removed year designation
[Done improperly.  Change “ISO/IEC:2024” to “ISO/IEC 24772-1:2024”.]

JP-079, 6.56.2, paragraph 1, line 2:
Change “6.56.5;” to “6.56.5.”.  --- Accepted
[Undone.]

JP-086, 7.3.1, paragraph 4, line 1:
Change “allocable” to “allocatable”.  --- Accepted.
[Undone.]

---------------------------------------------
In addition, I noticed the following in the latest draft:

In a reference to a subclause of ISO/IEC 24772-1, the comma between the
standard identifier and
the subclause number would be necessary.   However, those commas have been
deleted in the latest
draft, leaving “ISO/IEC 24772-1:2024, 6.18.5” as the only exception.   Such
commas appear in
the ISO editor's comments, for example.   They should be restored.

In 6.65.1, paragraph 1, line 1:
Change “ISO/IEC 6.65” to “ISO/IEC 24772-1:2024, 6.65”.

CN-085, 6.66, technical change (adding a new subclause):
The vulnerability as described in ISO/IEC 24772-1:2024 Amd 1 6.66 should be
added to this file
--- Added. No specific Fortran context is required.
[The amendment is still on the DAM ballot process, and its inclusion at
this stage is inappropriate.
The DAM ballot will end on 2026-08-11.]

In 7.3.1, the only paragraph at the time of the DIS ballot has been wrongly
itemized.   Undo it.
See at the bottom of this email.   (The wording might be improved by some
other itemization,
but not in this way.)

Unfortunately, I do not have enough time to check all other changes made.

---------------------------------------------
The following JP comments have been satisfactorily resolved, but would need
explanations.

JP-036, 4.10.4, paragraph 7, line 1:
Change “syncmemory” to “sync memory”.  --- Not found
[Done.  It was there, in the balloted version.  See attached.]

JP-039, 4.10.6, paragraph 5:
In the program, change “. . .[newline]code that” to “. . . code that”,
three times.
--- Rejected. The [newline] shows that the omitted code follows.  It is not
a comment on the line above.
[Done.  The balloted version looked as attached.  The latest version is
fine.]

Regards,

Makki

=========For Your Information================
---------the balloted draft------------------
7.3 Unformatted files
7.3.1 Applicability to language
In Fortran unformatted output of a variable or expression, the internal
representation of its value is written
exactly as it stands to the storage medium and can be read back directly
with neither roundoff nor conversion
overhead into a variable of the same type, type parameters, and shape. If
the variable is a pointer, for defined
behaviour, it must be associated with a target and the value of the target
is written; when read back the
target must have the shape of the target that was written. If the variable
is allocatable, it must be allocated;
when read back it must be allocated and have the shape of the variable that
was written. The variable is not
permitted to be of a type with an ultimate component that is allocable or a
pointer, unless a user-defined
derived type I/O procedure has been provided. If these prerequisites are
not satisfied, program behaviour
is undefined. In particular, if the file is read within a program execution
other than the one in which it was
written, there is a danger that incorrect values will be obtained, or that
the reading program runs out of
data prematurely.
---------the "latest" draft------------------
7.3 Unformatted files
7.3.1 Applicability to language
In Fortran unformatted output of a variable or expression, the internal
representation of its value is written
exactly as it stands to the storage medium and can be read back directly
with neither roundoff nor conversion
overhead into a variable of the same type, type parameters and shape. If
the variable is a pointer, for defined
behaviour, certain prerequisites apply:
   -  it is associated with a target and the value of the target is written
and when read back the target has
      the shape of the target that was written.
   -  If the variable is allocatable, it must be allocated and when read
back it must have the shape of the
      variable that was written.
   -  The variable is not permitted to be of a type with an ultimate
component that is allocable or a pointer,
      unless a user-defined derived type I/O procedure has been provided.
If these prerequisites are not satisfied, program behaviour is undefined.
In particular, if the file is read within
a program execution other than the one in which it was written, there is a
danger that incorrect values are
obtained, or that the reading program runs out of data prematurely.
---------------------------------------------

2026年7月4日(土) 3:45 Steve Lionel <[email-masked]>:

> This message is for WG5 (includes J3) members only.
>
>
> Stephen Michell, WG23 Convenor, wrote:
>
>
> “Erhard and I are doing a final edit on ISO IEC 24772-8 Fortran
> vulnerabilities before publication. I need a list of current Fortran WG
> members to do a last review for us.
>
>
> The document went through DIS ballot and had lots of editorial changes
> from the ISO editor, as well as comments from Japan.
>
>
> One of the purposes of the review is to ensure that we did not change
> anything that would cause us to go to FDIS ballot.”
>
>
> He asked me to send the relevant documents to WG5 for a final look-over. I
> have uploaded them to the WG23 folder in the J3 Meeting Files area. The
> files are:
>
>
>   WG23-N1567 - The  24772-8 Fortran vulnerabilities document from  ISO
> after ballot and with Editorial changes by ISO editor.
>
>
>   WG23-N1566 - The  ISO summary NB and editorial comment sheet with our
> responses.
>
>
>   WG23-N1571 - The 24772-8 document with our changes and responses to
> editor’s comments.
>
>
>   WG23-N1572 - The 24772-8 document as a difference between what came form
> ISO and Erhard’s and my end product.
>
> Please make any markups on that last document and send them to Stephen at
> [email-masked]
>
>
> Steve L
>

-- 
江戸川大学 元教員 高田正之
email: [email-masked]