ISO/IIEC JTC1/SC22/WG5 N1588

        Collected FCD edits from J3 meeting 167
                   11 Mar 2004
                  Richard Maine

The following suggested edits to the FCD were passed at J3
meeting 167.  These are in addition to those edits in
the US country position.

Typos and editorial errors

  Fix a serious implementation problem apparently introduced
  as a typo.  The bullet in question disappeared with no paper
  ever having passed such an edit.
    [298:7 lines from bottom] Insert a bullet before "char".

  [397:2] Delete "a"
  [409:18] Insert "or <ac-implied-do>" before the period.

  Note 12.9 switches randomly between talking about
  operators and operations, making it confusing.
  [262:Note 12.9 first line] "operators" -> "operations".

  The definition of binding label at [403:30] is nonsense for
  variables or common blocks, which are correctly done on the first
  line of the same page.
    [403:30] Add "of a procedure" after "binding label".

  Pointer objects.  The bnf for pointer assignment no longer uses
  the term <pointer-object>.  A few references to the old syntax
  remain.
    [74:4],[81:9],[423:34] Delete "<pointer-assignment-stmt> or"
    [74:4+],[81:9+],[423:34+] Insert new item
       "(x.5) A <data-pointer-object> or <proc-pointer-object> in
              a <pointer-assignment-stmt>,"
    [304:24] "<pointer-object>" ->
             "<data-pointer-object> or <proc-pointer-object>"

Clarification
  [285:3] "in an interface block" -> "by an interface body or
           procedure declaration statement"

Technical errors

  Pending I/O identifier.  It makes more sense and is more parallel
  with other syntax for input specifiers to take expressions instead
  of just variables.  Also, apparently HPF allows expressions here
  and the restriction to variables was likely just from accidental
  copying of the wrong case.
    [206:9],[210:21] "<scalar-int-variable>" -> "<scalar-int-expr>"
    Corresponding changes in D.1 are automatic.
    [206:18],[213:2] "variable" -> "expression"

  Specific intrinsics and KIND arguments.  When KIND arguments
  were added to several intrinsics, the effect on passing the
  specific intrinsics as actual arguments was overlooked.  It
  would be a major implementation issue to require that to work.
  It would also cause an incompatibility with f95 in that the
  addition of the new argument changes the characteristics of
  the interface.  Neither of these effects were intended; the
  addition of the KIND arguments was thought to be of low impact.
    [298:16+] Insert new para
       "In those cases where the corresponding generic function
        has an optional dummy argument named KIND, the specific
        function omits that argument.  The special meaning of the
        KIND argument is fundamentally a generic concept."

  Intent and construct association.  It is not necessary to say
  that an associating entity has the same INTENT attribute as its
  selector.  The appropriate restrictions implied by INTENT are
  phrased in such a way as to apply regardless.  More importantly,
  it is technically wrong in the case where the selector is
  a pointer because the association then is to the target of
  the pointer; INTENT attributes for the target would imply
  different restrictions than those for the pointer.
    [161:19] Remove "INTENT,".