J3/02-313 Date: 04 November 2002 To: J3 From: Aleksandar Donev Subject: C_LOC Corrections Reference: J3-007R3, J3/02-230r2 ______________________________________ Summary ______________________________________ Richard had some objections to the edits made in 02-230r2 in the section on the C_LOC and C_F_POINTER intrinsics, which I address in this paper, and propose some edits. Also some questions which need to be addressed by all of J3 are given. ______________________________________ Nontrivial issues ______________________________________ Some of the comments are not directly resolved or addressed: ______________ Richard thought the current Result explanations on C_LOC were vague and lacked the clarity needed for an independent reader to understand them. While I agree that they are far less then perfect, I believe they are adequate. ______________ 384: 17-19 Richard thinks we need to determine whether we really mean to impose the requirement that the target of PX "shall not have been deallocated". With ordinary pointer to pointer assignment PX=>PY, PY can be undefined and the assignment is legal but the results are not. We could do the same here, since we are now pointing a Fortran pointer to a Fortran pointer, FTPR=>PX, indirectly (i.e., via a C pointer CPTR). However, since we have a very strong requirement on CPTR in Case (i), i.e., we do not allow the C pointer to be invalid or null or anything like that, I think we ought to keep the same strong requirement here. Of course, no compiler will ever be able to check any of this anyway... ______________ 474: 31, 35 This example uses deferred bindings, which are at present not in the draft. Depending on what we do with them and how we adopt the syntax, line 31 should be updated accordingly. ______________ ______________________________________ Edits ______________________________________ Most of these edits are organizational and correct punctuation and lack of conditionals. They do not at all change any contents. _____________ 383: 3 Add Result Characteristics. Scalar of type C_PTR. and replace "Result" with "Result Value". _____________ Note 15.3 Replace C "base" address of the argument with hardware address of the storage associated with the argument _____________ 384: 16 Replace "were made. The association" with "were made and the association" _____________ 384: 6 Move the SHAPE paragraph to the end (i.e., right before NOTE 15.5) _____________ 384: 5-6 Richard, please see if this is OK with you. I still do not want to split the CPTR and FPTR paragraphs alltogether. They are related and I find the current version easier to understand then repeating the same thing twice. Make a heading CPTR and FTPR and make the current lines 5-6 into regular sentences. Something like: "CPTR shall be a scalar... FPTR shall be a pointer..." 384: 8- Add Either, Case(i)..., or Case(ii)... and also add a few more conditionals in the text of case (i) and (ii): 384: 11 Add: "In this case, FPTR shall..." 384: 20 "In this case, FPTR shall..." _____________ 474:2 Replace "real numbers, not supported" with "real numbers, which may not be supported" _____________ 474:23-24 Replace "modern OO random number generator" with "modern OO uniform random number generator (URNG)" _____________ 474: Add: as follows: to the end of the sentence instead of just a colon _____________ ! EOF