J3/06-356r1

Date: 14 November 2006
To: J3
From: Dick Hendrickson
Subject: Clause 13 Misc. issues
References: J3/06-007R1, 06-333, 06-353

355:7 Add " and false if it is not" at the end of the sentence

355:9 Add " and false otherwise" after "procedure"

378:14 It makes no sense to allow the FINDLOC value to
be an array.
Edit: Insert "scalar and " after "shall be".

384:3 None of the routines should cause undue anythings.
Implementers know what this is for.
Edit: Delete ", without overflow or underflow"
      Make a similar deletion at [350:13-14] for ABS

392:6 Why is IS_CONTIGUOUS limited to assumed-shape and
array pointers? Pages 87-88 give a whole list of
things that are contiguous. Many are obvious, but
we allow SQRT(0.) and LOGICAL(.TRUE.).
This subsumes paper 06-333 and possibly interacts with 06-353.
EDIT: Delete " assumed-shape".

410:8 As with HYPOT, they should do the right thing.
EDIT delete line 410:8

-------------------
Items for which no action or edits are needed

361:27+ (the line does not appear to be numbered.) Does the "nor
shall Y..." clause apply to "Y shall not be present" or
to "If X is..."? The sentence makes sense either way.

RESPONSE: The sentence is clear, the nor clause applies to the
initial "If X is " phrase.

376:16 Does EXECUTE_COMMAND_LINE cause normal or abnormal
termination if the command itself causes the termination?
Something like EXECUTE_COMMAND_LINE('stop me at noon")

RESPONSE: No edits needed here.  External interrupts are
likely to be abnormal terminations.  but that is not a property
of EXECUTE_COMMAND_LINE.

376:23 This says that command lines are executed synchronously
if the processor doesn't support asynchronous execution.
Actually, it might not support command lines at all, and
adding "wait=.false." is unlikely to force it to.
Edit: delete "; otherwise...synchronously".

RESPONSE: The description of CMDSTAT covers this odd case.

407:10-12 This paragraph describes the effects that the PURE
subroutine has on things that aren't its arguments.
MOVE_ALLOC can't be pure! This is probably a F2003
interp question, rather than a 2008 integration issue.
This also affects 339:13 and note 13.1.

RESPONSE: The standard allows pure subroutines to cause
pointers to change their status.