J3/98-183 Date: July 25, 1998 To: J3 From: Dick Hendrickson Subject: Interpretation Request: Is the TRANSFER Function Result Undefined? ------------------------- NUMBER: TITLE: Is the TRANSFER function result undefined? KEYWORDS: transfer function, undefined, processor dependent DEFECT TYPE: STATUS: The result value section of the TRANSFER function says "...If the physical representation of the result is longer than that of SOURCE, the physical representation of the leading part is that of SOURCE and the remainder is undefined." ^^^^^^^^^^^^^^^^^^^^^^^^^^ and case (ii) gives an example of a transfer of 3 reals to 2 complexes with the imaginary part of the second complex being undefined. Where can you use this form of TRANSFER. There's a general prohibition about referencing undefined things. Doesn't that apply to expressions containing TRANSFER as well? Something like X = transfer (four_bytes,eight_bytes) or X = transfer(transfer(four_bytes,eight_bytes), four_bytes) reference the undefined part. Maybe in the latter case we could say that the "reference" in the outer transfer doesn't "require the value" of all of its argument. But that seems like an odd reading to me. We can't use it for functions like SIZE, because they only allow their argument to be undefined if it is a single variable name (13.8.5). The only thing I can think of is passing to a procedure argument that has no INTENT specified but that uses the defined part of the argument as if it were INTENT(IN). The intent can't be specified because INTENT(IN) arguments must be defined on entry. Question: Should the phrase be changed from "the remainder is undefined" to "the remainder is processor dependent"? ANSWER: EDIT: SUBMITTED BY: Dick Hendrickson HISTORY: Submitted 7/25/98 The following is a reply from Malcolm to an informal question -------------------- From: malcolm@nag.co.uk (Malcolm Cohen) Errors-To: x3j3-request@zonker.ncsa.uiuc.edu X-Sequence: x3j3@ncsa.uiuc.edu 1998-205 Subject: (x3j3.1998-205) Re: informal question about the TRANSFER function To: x3j3@ncsa.uiuc.edu Date: Fri, 3 Jul 1998 16:46:21 +0000 (BST) Hi Dick, You might want to make this an interp request, but here is my opinion anyway. > The result value section of the TRANSFER function says > > "...If the physical representation of the result is longer than that > of SOURCE, the physical representation of the leading part is that of SOURCE > and the remainder is undefined." > ^^^^^^^^^^^^^^^^^^^^^^^^^^ I think this should say "processor dependent" or the usual other weasel words when we mean any value can result but it is legal. I.e. I don't think the word "undefined" was intended in its "definition status" interpretation. And if it was so intended, it is broken because a function reference *cannot* have an "undefined" definition status - the concept is only applicable to variables, see below. > and case (ii) gives an example of a transfer of 3 reals to 2 complexes > with the imaginary part of the second complex being undefined. > > Where can you use this form of TRANSFER. There's a general prohibition > about referencing undefined things. Doesn't that apply to expressions > containing TRANSFER as well? Something like This is a bit difficult. According to 2.5.4, definition status is something that variables have; it is not a property of an expression value. This is made more confusing by: "Any variable or function reference used as an operand shall be defined at the time the reference is executed." [97:1] The mention of function reference is confusing, because a function is not allowed to return without fully defining its result, viz "If the result variable is not a pointer, its value shall be defined by the function." [207:28] All in all, I would say that the standard is confusing/misleading viz: (1) "undefined" is being used to mean "not defined by this standard"; we should change it to "processor determined" to clarify this. (2) "or function reference" in [97:1] is spurious and should be deleted. However, I would take the definition of "definition status" in 2.5.4 as being definitive in disallowing the concept of "undefined [definition status]" function references. Cheers, -- ...........................Malcolm Cohen, NAG Ltd., Oxford, U.K. (malcolm@nag.co.uk)