This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
Re: signed/unsigned integer conversion for right shift seems
- From: Jonathan Wakely <jwakely dot gcc at gmail dot com>
- To: ptb at inv dot it dot uc3m dot es
- Cc: Liu Hao <lh_mouse at 126 dot com>, Peter dot T dot Breuer at gmail dot com, gcc-help <gcc-help at gcc dot gnu dot org>
- Date: Tue, 6 Feb 2018 15:57:19 +0000
- Subject: Re: signed/unsigned integer conversion for right shift seems
- Authentication-results: sourceware.org; auth=none
- References: <5a4c7714.12d45.1616bb64adf.Coremail.lh_mouse@126.com> <201802061550.w16Fo9lV015177@nbd.it.uc3m.es>
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.