"Also sprach Jonathan Wakely:" > >> 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 > > The specification of each operator of course! I am and have been looking straight at them, and I see nothing that says that conversions should not be applied to their operators. > You've been pointed to them multiple times now, 6.5.5, and 6.5.6, and > 6.5.7, and so on. They contain nothing (6.5.7 is the ony one on the bitwise shift operators; 6.5.5 is additive operators, 6.5.6 is multiplicative). We have been quoting what 6.5.7 says here. > Are you trolling or just stubborn and unable to accept the help you asked for? I would be grateful if you desisted from ad hominen attacks. WHAT, specifically, do you see in 6.5.7 that allows the conversion specified by the general rule of conversions 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. NOT to be applied? You've been hot on claiming you have done the pointing, but light on doing it! It should not be hard. > Maybe this will help: > http://en.cppreference.com/w/c/language/conversion#Usual_arithmetic_conversions The arguments of the following arithmetic operators undergo implicit conversions for the purpose of obtaining the common real type, which is the type in which the calculation is performed: binary arithmetic *, /, %, +, - relational operators <, >, <=, >=, ==, != binary bitwise arithmetic &, ^, |, the conditional operator ?: That's all. No ">>" operator there, so no maybe. Your claim is false there. > And specifically: > http://en.cppreference.com/w/c/language/operator_arithmetic#Shift_operators That's a different place ... it seems to say what we have already quoted in the standard. First, integer promotions are performed, individually, on each operand (Note: this is unlike other binary arithmetic operators, which all perform usual arithmetic conversions). The type of the result is the type of lhs after promotion. No integer promotions can be performed, since the args are already ints. There is no "Second". If they meant to say "Second: NO sign conversions MAY be performed, so what you get after (possibly vacuuous) int promotion you are stuck with, " then they forgot to say it. > But feel free to shift the goalposts again and insist that somebody > proves the correctness of those pages, or some other way to move the > burden of proof from your mistaken interpretation to everybody else. Please desist from ad hominen attacks and allegations. I have not moved the goalposts (from what?) and I have not insisted on anyone proving correctness (against what? the spec IS the specification and there is no higher arbiter of what is correct), or any "burden of proof" (what is that?). And what is "MY" "mistaken" interpretation? I am simply reading what it says. If you know where it says something that I have not read, pelase do say! There is no exception for >> to what I have seen it says must or may (it is not clear) happen in general with respect to conversions: 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. Shrug. I think that's meant as a "MUST". They forgot to make exception in the stanzas for >>. Maybe anything really is allowed by way of conversion or no conversion in >> on ints in some compilers, on some platforms? Do you happen to know? I checked tcc without finding a difference. Regards PTB
