"Also sprach Tadeus Prastowo:" > > where it says that conversion MAY NOT or MUST > > NOT be applied to the arguments of >>. > > Let's assume you could do one or more conversions as you wish. I do NOT WISH. I merely want to know what is specified. > certainly you know you have to follow the spec, don't you? Now the No! I had no idea! You mean I am not allowed to invent a blue unicorn as the result or let it kill my granny! That is such a relief! Thank you :-). > specification of ISO-IEC 1989:1999 says in Section 6.5.7 Paragraph 3: > "The integer promotions are performed on each of the operands. The No promotions are performed in this instance as integer promotions are to change smaller-than-int types to int types, and we start with int types. > type of the result is that of the promoted left operand." We are not interested in the type of the result. > Now, where do you want to perform your desired conversion? > Point A: > before "The integer promotions are performed on each of the operands"? No. Integer promotions (i.e., from a type smaller than int to int) are performed first always, and there are none here, as we start from ints. > Point B: before "The type of the result is that of the promoted left > operand"? That is not a "point" but a statement of the type of the result. It says it is the same as the type of the PROMOTED (not CONVERTED) left operand. That is fine by me. It will be signed int in this case, as zero promotions are applied to an int, leaving the type as signed int, and the type of the result therfore as signed int too. > Point C: after "The type of the result is that of the > promoted left operand"? That is not a "point" either. Perhaps you are not referring to the operation of the compiler, and you really mean "where in the text should we be thinking about"? If so, there is no single "point" in the text from which deductions are made, rather a set of statements from which we can make deductions, but as such your "points" (sorry, no dissing intended) B and C are irrelevant to the deduction since there has been no observation made or alleged as to the type of the result. > Or any other point I have not mentioned? Or > at two or more points that I have mentioned? None of the above are "points" in the operation of the compiler or the operational semantics of C. As "points" in a specification, A is the only one that has relevance, as the type of the result (which B, C treat of ) is not in evidence or contention. But it is vacuuous as promotions are not performed, the operands being ints to start with. Apologies for being literal and apparently insisting on "promotion" meaning "change to integer type from smaller type" but I don't have an option to understand other than what is explicitly written. If you mean "conversion" instead, please say. For conversion, the puzzle is why it is NOT done, since the rule If one operand has an unsigned type T whose conversion rank is at least as high as that of the other operand's type, then the other operand is converted to type T. seems to apply, and would cause the left argument to become unsigned int to match the right unsigned int, and the shift to become logical, not arithmetic, which does not happen. The best I can see is that WHEN and MANY are get-outs in The usual arithmetic conversions are rules that provide a mechanism to yield a common type WHEN both operands of a binary operator are balanced to a common type or the second and third operands of the conditional operator ( ? : ) are balanced to a common type. CONVERSIONS involve two operands of different types, and one or both operands may be converted. MANY operators that accept arithmetic operands perform conversions using the usual arithmetic conversions. After integer promotions are performed on both operands, the following rules are applied to the promoted operands: > Try it for yourself if you can do one or more conversions at any of Those are points in a text, not points in the operation of a compiler (or the runtime), so the sentence above (and below) is not well-formed. I cannot "try it", therefore. Or do you mean to try applying deductions at those points? I refuted that with "B, C are irrelevant because we do not care about the type of the result, which makes no difference", and A does not apply (no promotion is or can be done because the args are ints already). > the points I have mentioned without breaking the other part of the > spec. So, if there is no loophole, a good spec shall not mention any > other extra thing, shall it? Eh? "shall not"? I am afraid I cannot parse that last sentence. Maybe "should not"? Well, the point is that I cannot see a loophole allowing conversion NOT to be done EXCEPT possibly the use of WHEN and MANY in the passage I quoted and none has been pointed to yet. But the claim that the detailed specs of the >> operator say what's up seem not to be justified. They don't. They only relevant thing is what you quoted as A,B,C above, being para 3 of the "constraints". There is no exception to the general conversion rule I quoted: If one operand has an unsigned type T whose conversion rank is at least as high as that of the other operand's type, then the other operand is converted to type T. The best one can do seems to be the WHEN and MANY I commented on above. Anything else? Best Regards PTB
