I have to put my two cents to this interesting discussion. First of all, the LRM is indeed unclear on this point, and this is the reason this issue is raised over and over again. I think I agree with most arguments raised in the mail thread until now, Shalom's and Greg's and others ;) With regard to the effect the signed'() has, I think nobody argues that signed'() forces the type to signed while propagating the type context in upward direction. The main point of confusion, as I see it, is whether the signedness context is propagated from signed'() to its operand in downward direction. If it is, then, if the context is signed, and remains signed when it reaches the "leaf" operands of the expression, these operands should be sign-extended. In all other cases, they should be zero-extended. 11.7.2 is explicit about that: "If the operand must be extended, then it shall be sign-extended only if the propagated type is signed". So, is signedness context propagated from result of signed'() to its operand? The question of whether the operand of signed'() is (or should be) self-determined or context-determined is a part of this bigger question. For $signed() (as opposed to signed'()), the answer is quite clear, since $signed() is a function call and thus the type of its arguments is not affected by the function call context. Therefore, the signedness is not passed down. For signed'(), the answer is not clear, for several reasons: 1. 6.24.1 says "When changing the signing, the type of the expression to be cast shall pass through unchanged, except for the signing", but it doesn't elaborate which direction of the "pass" is affected, the upward, the downward, or both. It also doesn't make it clear what it means to "pass signing in a 'non unchanged form'". For upward direction, it most probably means forcing the signing for the result of the signed'(). However, for downward direction, it may mean either forcing the signing for the underlying expression or avoiding propagating the signedness context from above. The third option could be to pass signedness context from above as is, in case the sentence is meant to apply to upward propagation only. 2. 6.24.1 also says "The cast shall return the value that a variable of the casting type would hold after being assigned the expression" and we know from 11.7.3 that signedness of LHS of assignment doesn't affect the RHS. If the 6.24.1 excerpt from the first bullet is meant to affect the downward propagation direction too, then to avoid a conflict with the said here, the meaning of 'non unchanged form' should be avoiding propagating the signedness context from above (in line with Greg's opinion). 3. It is not clear whether the operand of cast operator should be considered context-determined or self-determined. The Table 11-23 in 11.6.1 was not updated with SV operators yet. I'm also not sure SV-BC's Issue 38 mentioned by Greg is indeed a good reason to treat the operand as context-determined, as this portion of the standard was subsequently overridden by 6.24.3 "Bit-stream casting" (as I understand), which doesn't mention the self vs. context determination, leaving the question open again. 4. It is not clear whether the cast operator itself should be considered a "simple operand" or not. Section 11.5 doesn't list it as an operand explicitly. However, the cast operator is a "primary" in BNF. This makes the 11.7.2's "When propagation reaches a simple operand as defined in 11.5 (a primary as defined in A.8.4), ..." very confusing. BTW, it would be very nice to rename the 11.5's "operand" term to something like "simple operand" to void ambiguity in the term itself, since it is used in both its meanings throughout 11.7. All of the above contribute to the confusion about this issue. To make the definition unambiguous, I think at least the following needs to be unambiguously defined: 1. How signedness is propagated from the context of signed'() to its operand? To recall, there are three options: a) it is propagated as is, b) a signed context is forced and c) signedness is self-determined. 2. How the size is propagated from the context of signed'() to its operand, if at all? Is the operand self-determined or context-determined? Once these questions are answered, one could unambiguously decide whether to apply sign or zero extension to the simple operands inside signed'() and to what size to extend them. I myself don't have a special preference to how it should be defined, but I agree with Brad and Shalom, that defining signed'() as having the same effect as $signed() (and same for unsigned'()/$unsigned(), of course) is a good idea as it would be easy to remember and understand. Defining the two as having different behavior (like if signed'()'s operand's size is context-determined) also has positive sides, but I'm not sure how the added value would compare against having different definitions for the two. --Yulik. --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Thu Jan 31 05:28:18 2008
This archive was generated by hypermail 2.1.8 : Thu Jan 31 2008 - 05:28:58 PST