(j3.2006) (SC22WG5.4780) Preliminary result of vote on N1929

[John Reid]

Van Snyder wrote:
> On Fri, 2012-09-14 at 13:07 +0100, John Reid wrote:
>> Here is the preliminary result of the ballot on N1929. I think there
>> is little
>> doubt that the ballot has failed.
>>
>> I have changed Van's vote to No and removed the first sentence of his
>> comments, which was
>>       Replace "must" by "shall" throughout.
>> Is this OK, Van?
>
> "Throughout" was perhaps too strong, as Malcolm pointed out.  But "must"
> isn't an ISO word, at least not in almost all of the contexts used in
> the Vulnerabilities report annex.
>
>> On the assumption that this is OK, I have also removed the last two
>> paragraphs of Malcolm's comments because they address the sentence
>> that has been removed.
>> Is this OK, Malcolm?
>
> I would keep them both, unless Malcolm crafts a statement that doesn't
> require the presence of my objection in order to make sense.

OK. I have done this.

Revised draft attached.

Cheers,

John.
-------------- next part --------------
                                       ISO/IEC JTC1/SC22/WG5 N1943-2

             Result of WG5 letter ballot on N1929

                         John Reid

N1935 asked this question

Please answer the following question "Is N1929 ready for forwarding to WG23 
as the Fortran Annex to TR 24772?" in one of these ways. 

1) Yes.
2) Yes, but I recommend the following changes. 
3) No, for the following reasons.
4) Abstain.

The numbers of answers in each category were:
2 for 1) Yes (Nagle, Whitlock). 
1 for 2) Yes, but I recommend the following changes (Burnus)
7 for 3) No, for the following reasons
        (Chen, Cohen, Corbett, Long, Muxworthy, Reid, Snyder)
1 for 4) Abstain (Maclaren)

The ballot has failed. 

Here are the responses in detail

_______________________________________________________________________

Daniel Chen

I vote "NO" as after reviewing the document and the comments from others, 
the document will need some more work.

_______________________________________________________________________

Tobias Burnus

Fortran.14 Null Pointer Dereferences [XYH]

I think the guidance should also recommend/mention nullifying pointers; 
it doesn't help with the issue itself, but the mentioned associated only 
works if the status is not undefined and as variables are never 
automatically initialized to null (contrary to other languages, where 
that happens at least for static/SAVE variables) and as one easily 
forgets to nullify them, I think one could mention it here.


Fortran.15 Dangling References to the Heap

"Do not pointer-assign a pointer to a target when the pointer has a 
longer lifetime than the target"

While it is implicitly both in that sentence and more explicitly in the 
standard: The pointer should also not outlive the lifetime of the target 
attribute of the target. I mean the following case "subroutine (a); 
target :: a; ptr => a" if the actual argument to "a" has neither the 
target nor the pointer attribute.


Fortran.22 Identifier Name Reuse

(I think Fortran lacks a way to disallow/restrict host association. 
Currently, one can get odd results if one forgets to declare a variable 
(e.g. "integer :: i") and accidentally uses the host-associated 
variable; and "implicit none" doesn't help. - I just saw that it is 
covered in Fortran.58)


Fortran.55 Undefined Behaviour [EWF]

"Specify the external attribute for all external procedures invoked"

While that avoids issues with intrinsic procedures, I think one should 
recommend an explicit interface, especially one provided via 
use-association or internal procedures. (That's already mentioned in 
[OTR], but here it sounds like an explicit "external" recommendation. I 
think one could also mention something like that in [LRM].)


Fortran.58
"Future standarization efforts should consider:"

I wonder how the following is supposed to work in general - and not only 
in very specific cases: "Requiring that processors have the ability to 
detect and report the occurrence within a submitted program unit of 
invalid pointer references during program execution."

Some of the other ideas sound fine - and I am especially looking forward 
to a means to restrict the host association, e.g.  noimport / import :: 
list / import, where a compiler could provide -fnoimport in a similar 
way to -fimplicit-none to find unintended host associations.

_______________________________________________________________________

Malcolm Cohen

No, because
(a) the document is far from ready, with many technical and editorial mistakes 
having been pointed out by others;
(b) the WG23 schedule does not need our input so urgently.

Additional comments.

A. Looking at Fortran.3.1

> The Fortran type system is a strong type system consisting of the type, the 
> kind, and in most circumstances, the rank, of a data object.

The rank is not part of the type in Fortran.

> The kind of an entity is a parameterization of the type.

I do not know what this is trying to say, but it is false.  Some types have more 
than one type parameter (e.g. CHARACTER) and indeed PDTs can have more than one 
"kind" parameter.  Some entities have no kind at all (e.g. derived types with no 
kind type parameter).

> Objects of the same type that differ in the value of their kind parameter(s) 
> differ in representation, and therefore in the limits of the values they may 
> represent.

This is false.  There is no such requirement on intrinsic types to differ in 
this way, and it is trivially false for (e.g.)
   TYPE t(k)
      INTEGER,KIND :: k
      REAL c
   END TYPE

> A processor must support two kinds of type real and must support a complex kind 
> for every real kind that it supports.

This is ambiguous (exactly two or at least two?).

Either "must" -> "is required to" (not "shall"), or reword as a statement of 
fact instead of a requirement, e.g. like
   "A conforming processor supports at least two kinds of type real and a 
complex kind corresponding to each supported real kind."

> Among the numeric types, coercion may result in a loss of information or a 
> wrong result.
...
> if an integer variable with a large value is assigned to an integer variable 
> whose range do not include the value, the result is wrong.

Ungrammatical and untrue.  A program that does this does not conform to the 
Fortran standard.  (The preceding sentence is also untrue, this one is just 
easier to see.)  A processor is not required to detect such violations, and may 
do anything.

> Objects of derived types are considered to have the same kind when their type 
> definitions are the same instance of text (which may be distributed among 
> program units by module use).

Untrue.

> (Sequence types and bind(c) types represent a narrow exception to this rule but 
> they are not generally used

This assertion is false.  Yes, the majority of derived types used are extensible 
types, but sequence and bind(c) are very commonly also used.

> Operators applied to derived types must be explicitly coded by the programmer.

I don't know why this is saying "operators", when "operations" is clearly what 
is intended.

There is no "the programmer".  Try
   "Other than default assignment, each operation on a derived type is defined 
by a procedure."

> These explicitly coded procedures can contain whatever checks are needed.

Overly casual language.  And why "can contain"?  This is meaningless blather. 
One could just as well write "These procedures can contain the complete works of 
Shakespeare.".  Were you not intending to make a recommendation?  And without my 
change immediately above, "procedures" are suddenly appearing with no 
antecedant; with my change above, this should begin "Such a procedure ...".

And What does "whatever checks are needed" mean?  This is less than meaningless 
blather.

> In addition to the losses mentioned in Clause 6,

Clause 6 of which document?  (Perhaps the WG23 base document, in which case this 
form is correct, but if the Fortran standard is meant then the full reference 
needs to be given.)

> assignment of a complex entity to a real entity results in the loss of the 
> imaginary part.

No data is lost.  All this separate witter about assignment and operations 
should just talk about conversions instead: converting complex to real 
necessarily produces a value with no imaginary part, but it is not "lost".

> Assigning from an object of extended type to one of base type may also incur 
> loss of data.

No data is lost.  It is still there.

> Intrinsic procedures may be used in declarations to supply desired kind values.

"Intrinsic functions may be used in constant expressions that calculate desired 
kind type parameter values."

B. Re Van Snyder's suggestion of blanket changing "must" to "shall"; instead, 
some/many/most/all of these should be reworded as statements of fact about 
conforming processors and programs.  When that is not appropriate or would leave 
to clumsy wording, "must"->"is required to" might be sufficient as an indication 
that the requirement is required by some other document than the one being read 
(I will have to think about this a bit more).

In any case, the document currently does not contain the word "shall", and this 
is good because this document is not a standard that should be attempting to 
place requirements on Fortran programs.

______________________________________________________________________

Robert Corbett
representing Oracle America

3) No, for the following reasons.

Oracle's standards board opposes the base document
TR 24772:2010.  I assume that Oracle's standards
board would oppose the Fortran Annex.  I asked for
explicit guidance on this question, but I have not
yet received a response.  Based on the information
available to me, I vote no.

_______________________________________________________________________

Bill Long

My vote is No. I read through N1929 and marked over 40 corrections, and 
probably missed others. I'll bring the markup to the October J3 meeting. 
Malcolm also found an extensive (and likely incomplete) list of 
problems.  In my opinion it is definitely not "ready for forwarding to 
WG23".

_______________________________________________________________________

David Muxworthy

I vote No.  The reason for voting No is that TR24772 is currently out
for SC22 ballot with deadline 2012-09-10.  Hence the next revision
will probably not be compiled by WG23 until May or June 2013.  This
gives WG5 the best part of a year to polish the document.  It would
be premature to submit N1929.

Were the timescales not inappropriate my vote would have been Ywc with
the following comments:

Fortran.1  Should also list corrigendum 1 and part 2.  (That is
assuming that ITTF get round to publishing the corrigendum soon.)

Fortran.1 (or elsewhere) Should give a list of earlier standards, in
the style used in F2008 Annex B.1, since Fortran 77 and 90 are
mentioned but never defined.

Fortran.2.1 More should be said about pre-F90 history.  F77 is clearly
still in widespread, if possibly sparse, active use and F77 programs
appear to be commonplace as evidenced by comp.lang.fortran and
comp-fortran-90.  Redundant facilities as far back as F66 continue to
be available in many compilers.  This situation should be described to
give context to what follows.  There is some possible text in my email
of May 11 to the vul-annex list.

Fortran.2.2 I am slightly confused by the heading "The following
definitions are taken from the Fortran standard".  These are not
necessarily word-for-word copies of the text in section 1.3 of the
standard and are a small subset of the definitions in 1.3. What is the
criterion for inclusion?

To be really picky, "assumed shape" and "assumed size" should have
hyphens to be consistent with subsequent text.

The definition "deleted feature: a feature that existed in Fortran 77
but has been removed from later versions of the standard" is not
strictly correct.  Here is a suggested replacement:

deleted feature: a feature that existed in an earlier version of the
standard but was subsequently deleted.  Certain redundant features in
Fortran 66, Fortran 77 and Fortran 90 have been deleted.


_______________________________________________________________________

John Reid

I vote no in this ballot. It is clear from the comments of others that 
this document needs more work.

_______________________________________________________________________

Van Snyder

2) Yes, but I recommend the following changes. 

Replace "must" by "shall" throughout.  Check throughout whether "may"
ought to be "might" (almost always).  Check throughout whether "when"
should be "where" or "if" (almost always).

Page 2, paragraph beginning "A program conforms": delete the second
sentence ("Where the standard fails...") because it is redundant to the
first paragraph on page 3 (or delete the first paragraph on page 3).

Page 2, paragraph beginning "Annex B.1": replace "compilers" by
"processors".

Page 2, paragraph beginning "The Fortran standard defines a set of
intrinsic procedures": replace "intrinsics" by "intrinsic procedures".

Page 3, paragraph beginning "The values of data objects": Delete "that
are guaranteed to be represented correctly" because it might leave the
empty set.

Page 4, first paragraph, replace "compilers" by "processors" four times.
Delete "this" from "change this existing software".

Page 5, first paragraph of Fortran.3.1, insert a penultimate sentence
"Double precision real shall provide more digits of decimal precision
than default real."

Page 6, line 2, replace "range do not" by "range does not".

Page 6, paragraph beginning "Derived types", insert "For derived type
objects," before "Type changing assignments".  Delete final sentence.

Page 6, paragraph beginning "In addition to", specify what is Clause 6.
Is it the clause in the Fortran standard, or a clause of the main body
of 24772?

Page 7, third paragraph of Fortran.4.1, replace "manipulating" by
"manipulation".

Page 9, second bullet in Fortran.5.2, replace "Do not create" by "Avoid
creating".  There are circumstances where equality (or inequality) is
required, such as testing for zero.

Page 9, third bullet in Fortran.5.2, either delete this item, or remark
that it relies on a deleted feature.

Page 9, fifth bullet in Fortran.5.2, replace "Avoid getting or setting"
by "Avoid the use of bit operations to get or set", or "Do not use bit
operations to get or set".

Page 9, sixth and seventh bullets in Fortran.5.2, replace "when" by
"where".

Page 12, paragraph beginning "The Fortran standard requires": replace
"with" by "during".

Page 12, paragraph beginning "When a whole-array": delete second
sentence as it is redundant with the next paragraph.

Page 12, paragraph beginning "When a character assignment": replace
"size" by "length".

Page 13, first bullet on that page, replace "whenever" by "wherever".

Page 13, second bullet on that page, replace "when arrays" by "when
array".

Page 13, third bullet on that page, replace "when" by "where".

Page 13, second paragraph of Fortran.10.1, replace "with" by "during".

Page 14, fourth bullet of Fortran.10.2, replace "whenever" by
"wherever".

Page 14, fifth bullet of Fortran.10.2, replace "when" by "where".

Page 15, fourth bullet of Fortran.11.2, replace "whenever" by
"wherever".

Page 15, fifth bullet of Fortran.11.2, replace "when" by "where".

Page 16, second paragraph of Fortran.12.1, replace "may" by "might".

Page 17, subclause Fortran.14.1, add a paragraph after the first one
"Fortran pointers by default are initially undefined, not nullified".

Page 17, subclause Fortran.14.2, add  bullets "o Explicitly nullify
pointers if there is a possibility their association status might be
inquired before they are associated. o Use default initialization in the
declarations of pointer components. o Use initialization in the
declarations of all pointers that have the SAVE attribute."

Page 18, first bullet, replace "whenever the pointer has" by "if the
pointer might have".

Page 18, add a second bullet, "Do not pointer-assign a pointer to a
target if the pointer might have a longer lifetime than the TARGET
attribute of the target."

Page 18, first bullet of Fortran.16.1, insert "procedure" after
"intrinsic".

Page 20, subclause Fortran.21.2, add a bullet "Use compiler options
where available, or a static analysis tool, to detect variables to which
a valis is assigned but that are not referenced."

Page 21, second bullet of Fortran.22.2, replace "whenever" by
"wherever".

Page 21, first bullet of Fortran.23.2, add "Use implicit none to enforce
this."

Page 22, first paragraph of Fortran.25.1, delete sentence "These
operators have the same precedence order for defined operations" because
it is false.

Page 25, second bullet in Fortran.28.2, replace "every statement is
executed" by "the test suite causes every statement to be executed".

Page 25, fourth bullet in Fortran.28.2, delete "of a computational
algorithm".

Page 27, second bullet of Fortran.32.2, replace "when" by "wher".

Page 28, third paragraph of Fortran.34.1, replace "may have" by "has";
replace "when" by "if" or "where"; replace "interface block" by
"interface body" twice.  Replace "return values" by "result variables".

Page 29, first bullet of Fortran.35.2, replece "whenever the pointer
has" by "if the pointer might have".

Page 29, subclause Fortran.35.2, add a second bullet "Do not
pointer-assign to a target if the pointer might have a longer lifetime
than the TARGET attribute of the target.

Page 29, second bullet of Fortran.35.2, replece "whenever" by
"wherever".

Page 30, second bullet of Fortran.36.2, replace "interface blocks" by
"interfaces" or "interface bodies".

Page 30, first bullet of Fortran.37.2, delete "when evaluating
mathematical quantities".

Page 31, second bullet of Fortran.38.2, insert "intrinsic or" before
"library".

Page 32, subclause Fortran.41.2, add a bullet "Use a tool during testing
to detect memory leaks."

Page 33, second bullet of Fortran.43.2, add a sentence "Give the
component the PRIVATE attribute."

Page 33, subclause Fortran.44.1, replace "intrinsics" by "intrinsic
procedures" twice.

Page 34, subclause 45.2, add a bullet "Provide explicit interfaces using
interface bodies for library procedures that are not module procedures."

Page 34, first sentence of Fortran.46.1, replace "may" by "can".

Page 35, subclause Fortran.48.2, replace "interface blocks" by
"interface bodies".  Add a bullet "Prefer libraries that provide
procedures as module procedures rather than external procedures."

Page 36, second and third paragraphs of Fortran.50.1, replace "may" by
"might" thrice.

Page 36, third bullet of Fortran.50.2, replace "whenever" by "wherever".

Page 37, first paragraph of Fortran.51.1, replace "compilers" by
"processors".

Page 37, third bullet of Fortran.51.2 replace "compilers" by
"processors".

Page 38, first bullet of Fortran.52.2, replace "interface block" by
"interface body".

Page 38, second paragraph of Fortran 53.1, replace "may" by "might".

Page 39, subclause Fortran.55.2, add bullets
"o Avoid use of nonstandard intrinsic procedures.
 o Specify the INTRINSIC attribute for all nonstandard intrinsic
   procedures."

Page 40, first paragraph of Fortran.57.1, replace "compilers" by
"processors".  Replace "may" by "might".

Page 41, after sixth bullet of Fortran.58.1, add a bullet "Requiring
that processors have the ability to detect and report the occurrence
within a submitted program unit of pointer assignment of a pointer whose
lifetime is known to be longer than the lifetime of the TARGET attribute
of the target."

Page 42, add a bullet "Providing a method to specify units of measure
for numeric variables, rules for combining variables for which units of
measure are specified, facilities for checking and converting units of
measure during formatted input, and facilities for displaying units of
measure in formatted output."