J3/06-272

Date:    3 August 2006
To:      J3
From:    Aleksandar Donev
Subject: Notes on clauses 14-16 of F2008 draft

References: 06-007

I split the comments into several categories:
1) Simple editorial corrections
2) Requests to clarify or change wording
3) Technical issues that I do not understand or I find badly designed
and in need of fixing.

_________________________________
Editorial corrections
_________________________________

1.
[487:?] The BITS part of the table is not formatted properly due to line overflow.

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

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

4.
[497:1+] Shouldn't the bullets be numbered? Similarly for [498:9-13].

5.
[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.


_________________________________
Changes of wording
_________________________________

1.
[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"

2.
[474:6+] We need to restrict FPTR from being co-indexed, since C_F_POINTER is another means of performing pointer assignment (which has this restriction).
"FPTR shall be a pointer that is not a co-indexed object"
Similarly for FPTR argument of C_F_PROCPOINTER.

3.
[475:6] Add to the end of the sentence describing the argument X:
"that is not a co-indexed object"

4.
[475:19] We should replace this line with:
"X shall not be a co-indexed object and it shall either"

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

6.
[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.

7.
[481:20+] In Note 15.18 delete the second sentence "Such arrays...".

8.
[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."

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

10.
[499:23] We should mention STORAGE_SIZE here with a cross-ref.

11.
[503:21+] We should say here that the dynamic type of the associating entity is that of the pre-existing entity. Dummy arguments can be polymorphic without being pointer or allocatable and thus are not covered by [503:15-17].

_________________________________
Technical questions
_________________________________

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.

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

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

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

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.