J3/06-272r1

Date:    15 August 2006
To:      J3
From:    Rob James
Subject: Notes on clauses 14-16 of F2008 draft

References: 06-007, 06-272


Edits
-----

[478:Table 15.2] The BITS part of the table is not formatted properly.

[485:12] Insert a space after (16.5.1.5).

[491:8]  Add space after (4.5.5).

[472:1+] In Note 15.2 replace "might find it helpful...module by a
         processor dependent means" with "might provide a means to
         select from....module by processor-dependent means".

[474:6+] At the beginning of the description of FPTR, after "shall be
         a pointer", insert "that is not a co-indexed object".

[475:1]  At the beginning of the description of FPTR, after "shall be
         a procedure pointer", insert "that is not a co-indexed
         object".

[475:6]  Before "shall either", insert "shall not be a co-indexed
         object and".

[476:19,22] Replace "an object" with "a scalar object" twice.

[479:1-] In Note 15.9, remove the second sentence.  Also change
         "Instead a user can use the signed" to "A user can use bits
         or the signed".

[483]    In Note 15.23, after "type C_PTR" in the first line of the
         last paragraph, add "with the VALUE attribute".

[503:18] Change "definition status and value (if it is defined)" to
         "definition status, value (if it is defined), and dynamic
         type".

[503:18-21] This paragraph should be number (3) in the preceding list.


Questions for the editor
------------------------

[497:3-19] Should these bullets be numbered?  Similarly for [498:9-13].


Answers to technical questions in 06-272
----------------------------------------

Question 1:
  [475:15+] Why isn't there a paragraph equivalent to [476:6-8] for
  C_FUNLOC as well? It seems to me we never really explain what
  C_FUNLOC returns in terms of C semantics.

Answer 1:
  This is not necessary for functions, and in other ways, the result
  value descriptions are parallel.


Question 2:
  [487:20-29] Following my objections raised in Interp F03/0076
  (Scope of Fortran names of procedures with binding labels), I believe
  that we should remove the names of external procedures with binding
  labels from the list of names with global scope. It is the binding
  label that is of global scope and used to invoke the procedure from
  other scoping units. The Fortran name of the procedure is merely a
  dummy name used to locally identify the binding label and make the
  name case-insensitive if needed. The following edits would seem to
  implement this and still be backward compatible:
    [487:21] After "or external procedure" add "without a binding
             label"
    [487:28] Replace "that is not" with "without a binding label other
             than"
    [488:?]  In Note 16.2, in the first line, add "without a binding
             label" after "external procedures"
    [489:6]  Add "or subroutines with binding labels" before the ")"
    [489:10] Add "or functions with binding labels" before the ")"

Answer 2:
  Subgroup does not agree. The Fortran name CAN be used to reference
  the procedure from other Fortran program units.


Question 3:
  [491:30] How can an entity declared in a BLOCK construct be
  accessed by use association?

Answer 3:
  This is discussed extensively in Malcolm's paper 254.


Question 4:
  [500:7-8] What is the purpose of this sentence? And what does
  "amount of storage" really mean?

Answer 4:
  See paper 06-233 (the reply paper for Unresolved Technical Issue 77).


Question 5:
  Can co-arrays be used to copy a pointer from one image to another,
  for example, by using polymorphism to add such pointer components to
  a type? If yes, then we should say that the value of the copy is
  undefined.

Answer 5:
  This is related to ALLOCATE(X,source=poly_thing) where poly_thing has
  pointer components.  This issue seems to also be somewhat related to
  paper 06-243.  This issue may need to be considered when processing
  that paper.


No action for the following comments
------------------------------------

[475:19] Before "shall either", insert "shall not be a co-indexed
         object and".
Covered in 06-208r3.

[479:3+] Reword Note 15.12:
         a) delete the last sentence of the first paragraph
            (allocatable variables and procedures can be passed as
            actual arguments without involving TYPE(C_PTR) or
            TYPE(C_FUNPTR)),
         b) replace the first line of the second paragraph with
            "For example, type C_FUNPTR and C_PTR can be used for
            components of interoperable types."
         c) Delete the ending ", even in contexts..." (it is
            duplicate), and
         d) merge the two paragraphs into one.
Subgroup believes the current note to be better than the modified one.

[481:20+] In Note 15.18 delete the second sentence "Such arrays...".
Subgroup believes this to be unnecessary.

[481:20+] Note 15.19 might not conform to the C standard.
          Multi-dimensional arrays are arrays of pointers.
This could be a problem.  We'll wait for a response from J11.

[482:0] In Note 15.20, add to the third paragraph the sentence:
        "It is the programmer's responsibility to add the trailing
        null character where necessary."
Subgroup believes this to be unnecessary.

[497:7-12-] Doesn't the third item and the associated Issue 75 note
            not belong in 16.5.3.2? It seems to have been placed here
            by mistake.
Covered in 06-231.

[499:23] We should mention STORAGE_SIZE here with a cross-ref.
Subgroup believes this to be unnecessary.