Re: signed/unsigned integer conversion for right shift seems

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 6 February 2018 at 17:19, Peter T. Breuer wrote:
> "Also sprach Jonathan Wakely:"
>> >> No, because the operands of bitshift operators aren't balanced to a common type.
>> >
>> > Where does it say that? Your word isn't quite enough for me :-(.
>>
>> You've already been told that 6.5.7 says "The integer promotions are
>> performed on each of the operands. " and says nothing about
>> conversions.
>
> If that were a valid mode of reasoning it would apply to the operands of
> arithmetic operators to which conversion IS applied.  (Which are they?)
>
> Ergo, it is not. No flowers in this instance :-(.
>
> Is there somewhere where it DOES say that conversions should be
> applied to SOMETHING?
>
>> > It doesn't require the rules to be applied, it only talks about WHEN
>> > they are applied. It leaves it open as to to which operators that
>> > the conversion rules are to be appled to.
>>
>> The specification of each operator tells you if it's applied. 6.5.7
>> doesn't say they are, so they aren't.
>
> 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.

> I wonder if I could I ask you to quote the ">>" specification for my
> lazy self?

6.5.7 in C99 or C11

> 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."
6.5.6 "The usual arithmetic conversions are performed on the operands."
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."
6.5.9 "If both of the operands have arithmetic type, the usual
arithmetic conversions are performed."
etc.

This was already said in the thread:
https://gcc.gnu.org/ml/gcc-help/2018-02/msg00020.html



> BTW, NOT saying something is applied in a specification should not mean
> that it is forbidden, as a general principle of specification languages.
> Is there somewhere in the C specification general blurb that says "no
> say, no do"?

When performing a conversion changes the observable behaviour of the
program, of course it shouldn't be done when the standard doesn't say
to do it.


> I admit my reason for supposing PROMOTION is not done was because I
> could find no rule that says to.  But in that matter I am willing to
> believe it can or cannot be done in some (other) compiler
> implementation, whatever it should amount to in that case. Not doing
> is what happens with gcc.
>
>> > No, I conclude whatever is logically required, and point out false
>> > aka mistaken logic where it is attempted. I don't mind what answer
>> > you or I get, so long as it is reasoned correctly, or at least
>> > convincingly.
>> >
>> > I haven't yet seen a constructive argument towards what I see as
>> > the probable out - that >> is just one of the 3 or 4 exceptions.
>>
>> Then you're not paying attention.
>
> You seem loathe to quote where it says that conversion MAY NOT or MUST
> NOT be applied to the arguments of >>. Unfortunately I can't work off
> word of mouth.

Whatever, feel free to report a bug to every C compiler. I'm not going
to waste any more time.



[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux