This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: signed/unsigned integer conversion for right shift seems


On 6 February 2018 at 15:50, Peter T. Breuer <ptb@inv.it.uc3m.es> wrote:
> "Also sprach Liu Hao:"
>> Well you could have declared the `printf()` function:
>
> Admitted, m'lud.  But that would have meant an extra line of code, and I
> am miserly.
>
>>     extern int printf(const char *restrict format, ...);
>>
>> > % ./a.out
>> > 0xe0000001
>> >   ^ SIGNED right shift
>> >
>> > OK, so x>>y was done signed. That means both x,y were converted to
>> > signed int (trivially).
>>
>> No. See below.
>
> I do not agree with the point made below, ingenious though it seems to
> me, hinging (apparently) on the meaning of "the". But let us see ...
>
>> > First: NO INTEGER PROMOTION is done, by this rule
>> >
>> >   any operand whose type ranks lower than int is automatically converted
>> >   to the type int, provided int is capable of representing all values of
>> >   the operand's original type.  If int is not sufficient, the operand is
>> >   converted to unsigned int.
>> >
>> > Both x and y are int, so do not rank "lower than int". Rule does not
>> > apply. All as is. So INTEGER CONVERSION applies from there:
>>
>> It doesn't.
>>
>> I don't have C99 at hand, so I will quote C11 (WG14 N1570) for you:
>>
>> ```
>> 6.5.7 Bitwise shift operators
>>   ...
>>   Semantics
>> 3 The integer promotions are performed on each of the operands.  ...
>> ```
>>
>> Note that the standard references _the integer promotions_, in contrast
>> to what you see elsewhere:
>
> I am afraid that "the" may refer to something that does not exist
> but is properly identified, such as "the large white rabbit that
> I met yesterday between the third and fourth pubs". It's a definite
> article, not a claim of cardinality at least one.
>
> That interpretation is helped by the "S" on the end of "promotionS",
> because in the case of an empty set of things, we still refer to the
> things in the empty set as being thingS [whereas I grant you it
> would be odd to refer to the thing (singular) in the empty set].
>
> In other words, the plural allows for 0,1,2,... number of promotions
> to be applied. I can find no rule that applies a promotion, so I
> contend the answer is 0.
>
> The horses that almost ran me over yesterday are a figment of my
> imagination.
>
>> 6.5.5 Multiplicative operators
>>   ...
>>   Semantics
>> 3 The usual arithmetic conversions are performed on the operands.
>
> Those are conversions, not promotions. I aver that zero PROMOTIONS
> and one CONVERSION (to UNSIGNED int) should be applied by the
> rule I quoted.
>
>> ```
>> 6.5.9 Equality operators
>>   ...
>>   Semantics
>> 4 If both of the operands have arithmetic type, the usual arithmetic
>>   conversions are performed.
>
> Ditto.
>
>> Clearly, the type of the operand on the right-hand side is not altered -
>> it remains `unsigned int`.
>
> Yes. And arithmetic operations are applied to operands of the same
> type. That's what conversion is for:
>
>   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   ...
>
> Ergo, one was unsigned, so they should both have been.

No, because the operands of bitshift operators aren't balanced to a common type.

You asked for clarification and have got your answer, but seem
determined to stick to your original interpretation.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]