"Also sprach Jonathan Wakely:" > >> The specification of each operator tells you if it's applied. 6.5.7 > >> doesn't say they are, so they aren't. (attempt to apply no say = must not ignored for the purposes of a communicative interaction with the humanZ here ...) > > I don't have a "specification of each operator" to look at ... probably > > it doesn't junp out from google for me as easily as other stuff does. > > See the C standard. Where specifically? I am now looking at the draft standard for ISO-whatever at http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf I am working through the 194 instances of the word "arithmetic" and the closest I have seen to a statement on the subject is in footnote 48 under paragraph 6.3.13 (I think .. can't see all the page) which says: The integer PROMOTIONS are applied only: as part of the usual arithmetic CONVERSIONS, to certain argument expressions, to the operands of the unary +, -, and ~ operators, and to both operands of the shift operators, as specified by their respective subclauses. which says (wrongly IMO) that promotions are some part of conversions, but we know what they mean. At any rate the implication is that CONVERSIONS, comprising as per their language a carrier for PROMOTIONS, ARE applied to BOTH operands of THE SHIFT OPERATORS, which seems to me to imply that both operands must be cast to the same type, otherwise to what type are they to be converted? Perhaps it has an exception in the "their respective subclauses" get-out. Where is that ... > > I wonder if I could I ask you to quote the ">>" specification for my > 6.5.7 in C99 or C11 Hmm ... [goes looks in what he has] ... yes, that is semantics for bitwise shifts: The integer promotions are performed on each of the operands. None are performed in this case, but there's that text from footnote 48 that I quoted above which says that promotions are part of conversions, so no promotions implies no conversions. That is, unless they mean that "as part" in the footnote may apply to a nonexistent part, in which case conversions may still happen because they would contain the nonexistent part consisting of the nonexisting promotion that was not done - I hope I am being clear. (for completeness, the rest of the para ...) The type of the result is that of the promoted left operand. If the value of the right operand is negative or is greater than or equal to the width of the promoted left operand, the behavior is undefined. (seems irrelevant here) Is it intended to be a free-for-all, do you know? > > Perhaps also let me know what else conversion does and does not apply > > to? > > 6.5.5 "The usual arithmetic conversions are performed on the operands." Those say 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. which would convert the (left, signed) int type to the (right, unsigned) int type. That has not been done. I'm beginning to deduce there is a right old mess here. Glad we caught it! Who knows what confusion might occur if this language ever sees the light of day! > 6.5.6 "The usual arithmetic conversions are performed on the operands." Ditto. If TUAC are applied they make both arguments unsigned int in this case by the rule "If one operand has an unsigned type T ..." that I quoted above and that does not happen, so either there an no conversions that apply or there is some kind of exception written down somewhere. I think we should just stop parsing text for sense in this instance and say they got the language wrong in the spec, but we know what they mean. > 6.5.7 [no mention of arithmetic conversions] > 6.5.8 "If both of the operands have arithmetic type, the usual > arithmetic conversions are performed." Ditto. > 6.5.9 "If both of the operands have arithmetic type, the usual > arithmetic conversions are performed." > etc. Ditto. > This was already said in the thread: What "this"? Nothing has been said so far that amounts to a constructive argument telling us whether or whether not "the usual arithmetic conversions" must or may or must not or may not be performed for a shift operator. The best I have seen is that the words WHEN and MANY 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: allow complete freedom of what happens. And I offered that explanation. > https://gcc.gnu.org/ml/gcc-help/2018-02/msg00020.html That is indeed THIS thread. Can you be specific about what the THIS is that you say was said? It appears from your words to apply to "If both of the operands have arithmetic type, the usual arithmetic conversions are performed" which does not happen, unless you think the "usual" is different from 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. Do you? It's OK if the text is not decisive, so long as it is determined logically that it is so. You likely can point to more of the relevant paragraphs. Regards PTB
