signed/unsigned integer conversion for right shift seems against C99 rule

signed/unsigned integer conversion for right shift seems against C99 rule

[Peter Breuer]

int main() {
  signed   int x = 0x80000005u;
  unsigned int y = 0x00000002u;
  signed   int z = x >> y;
  printf("0x%0x\n", z);
  return 0;
}
% gcc -std=c99 test.c 
test.c: In function 'main':
test.c:6:3: warning: implicit declaration of function 'printf' [-Wimplicit-function-declaration]
   printf("0x%0x\n", z);
   ^
test.c:6:3: warning: incompatible implicit declaration of built-in function 'printf'

(I'll live with that warning - just for the purpose of a clean example!)

% ./a.out
0xe0000001
  ^ SIGNED right shift

OK, so x>>y was done signed. That means both x,y were converted to
signed int (trivially).

However, that seems against C99 rules, which seem to say one should
convert to unsigned int in mixed sign equal rank situations.

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:

  If both operands are integers, integer promotion is first performed on
  both operands.  If after integer promotion the operands still have
  different types, conversion continues as follows:

They still have "different types", one being signed int and the other
being unsigned it. So CONVERSION happens:

  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.

We're there. Both are rank "int" so "at least as high" applies. One
(y) has an unsigned type T="unsigned int", so the other (x) must
be converted to T="unsigned int". Then the operation gets done as
  
 unsigned int >> unsigned int

Except it doesn't. The sign bit on the LHS was extended as the printf
showed with its "0xe..." at the front, so a shift-right-arithmetic got
done, not a shift-right-logical.

If you wonder if a SRL is available at all, it is.  Declaring both x and
y as unsigned int (i.e., change decl of x only to unsigned int) gives
the expected SRL output.

  % ./a.out
  0x20000001
    ^ zero-extended from 0x8..., not sign-extended. That's a SRL, not a SRA.

What am I reading wrong in the standards?  (which are nigh on
incomprehensible - what does "can be represented as" mean?  One can't
represent negative numbers in the unsigned version of the same type
ever, and one can't represent large positive numbers in the signed
version of the type ever, so one can never get "can be represented as").

Is this intended? Well-known to everyone but me?


% gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i586-linux-gnu/4.9/lto-wrapper
Target: i586-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.9.2-10'
 --with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs
 --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
 --program-suffix=-4.9 --enable-shared --enable-linker-build-id
 --libexecdir=/usr/lib --without-included-gettext
 --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.9
 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
 --enable-libstdcxx-debug --enable-libstdcxx-time=yes
 --enable-gnu-unique-object --disable-vtable-verify --enable-plugin
 --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk
 --enable-gtk-cairo
 --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-i386/jre
 --enable-java-home
 --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-i386
 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-i386
 --with-arch-directory=i386
 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc
 --enable-targets=all --enable-multiarch --with-arch-32=i586
 --with-multilib-list=m32,m64,mx32 --enable-multilib
 --with-tune=generic --enable-checking=release --build=i586-linux-gnu
 --host=i586-linux-gnu --target=i586-linux-gnu Thread model: posix gcc
 version 4.9.2 (Debian 4.9.2-10) 

The gcc notes at https://gcc.gnu.org/c99status.html seem to say 

  integer constant type rules   GCC 3.3 
  integer promotion rules GCC 4.0 

and nothing else.  Where is current information on standards compliance?
The manual  says

  c99
           c9x
           iso9899:1999
           iso9899:199x
           ISO C99.  Note that this standard is not yet fully supported;
                                               ^^^^^^^^^^^^^^^^^^^^^^^^
           see <http://gcc.gnu.org/gcc-4.7/c99status.html> for more
           information.  The names c9x and iso9899:199x are deprecated.



Any info that would deconfuse me?

Regards to any language lawyers who pass by on the other side or this side.

PTB

Re: signed/unsigned integer conversion for right shift seems against C99 rule

[Tadeus Prastowo]

On Tue, Feb 6, 2018 at 4:03 PM, Peter Breuer <peter.t.breuer@gmail.com> wrote:
> int main() {
>   signed   int x = 0x80000005u;
>   unsigned int y = 0x00000002u;
>   signed   int z = x >> y;
>   printf("0x%0x\n", z);
>   return 0;
> }
> % gcc -std=c99 test.c
> test.c: In function 'main':
> test.c:6:3: warning: implicit declaration of function 'printf' [-Wimplicit-function-declaration]
>    printf("0x%0x\n", z);
>    ^
> test.c:6:3: warning: incompatible implicit declaration of built-in function 'printf'
>
> (I'll live with that warning - just for the purpose of a clean example!)
>
> % ./a.out
> 0xe0000001
>   ^ SIGNED right shift

To quote ISO-IEC 9899:1999 draft
(http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf) Section
6.5.7 Paragraph 5: The result of E1 >> E2 is E1 right-shifted E2 bit
positions.  [...]  If E1 has a signed type and a negative value, the
resulting value is implementation-defined.
End quote.

So, getting what you got should not surprise you, should it?

> PTB

--
Best regards,
Tadeus

Re: signed/unsigned integer conversion for right shift seems against C99 rule

[Liu Hao]

On 2018/2/6 23:03, Peter Breuer wrote:
> int main() {
>   signed   int x = 0x80000005u;
>   unsigned int y = 0x00000002u;
>   signed   int z = x >> y;
>   printf("0x%0x\n", z);
>   return 0;
> }
> % gcc -std=c99 test.c 
> test.c: In function 'main':
> test.c:6:3: warning: implicit declaration of function 'printf' [-Wimplicit-function-declaration]
>    printf("0x%0x\n", z);
>    ^
> test.c:6:3: warning: incompatible implicit declaration of built-in function 'printf'
> 
> (I'll live with that warning - just for the purpose of a clean example!)
> 

Well you could have declared the `printf()` function:

    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.

> 
> However, that seems against C99 rules, which seem to say one should
> convert to unsigned int in mixed sign equal rank situations.
> 
> 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:

```
6.5.5 Multiplicative operators
  ...
  Semantics
3 The usual arithmetic conversions are performed on the operands.
```

```
6.5.9 Equality operators
  ...
  Semantics
4 If both of the operands have arithmetic type, the usual arithmetic
  conversions are performed.
```

Clearly, the type of the operand on the right-hand side is not altered -
it remains `unsigned int`.




-- 
Best regards,
LH_Mouse

Re: signed/unsigned integer conversion for right shift seems against C99 rule

[Alexander Monakov]

See the definition of "usual arithmetic conversions" in the text of the standard
and note that they are not applied to bitwise shift arguments (they undergo
integer promotions individually).

HTH.
Alexandr

Re: signed/unsigned integer conversion for right shift seems against

[Peter T. Breuer]

"Also sprach Tadeus Prastowo:"
> > int main() {
> >   signed   int x = 0x80000005u;
> >   unsigned int y = 0x00000002u;
> >   signed   int z = x >> y;
> >   printf("0x%0x\n", z);
> >   return 0;
> > }
> > % ./a.out
> > 0xe0000001
> >   ^ SIGNED right shift
> 
> To quote ISO-IEC 9899:1999 draft
> (http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf) Section
> 6.5.7 Paragraph 5: The result of E1 >> E2 is E1 right-shifted E2 bit
> positions.  [...]  If E1 has a signed type and a negative value, the
> resulting value is implementation-defined.
> End quote.
> 
> So, getting what you got should not surprise you, should it?

Suitably snide, but fashionably wrong. The type of E1 is UNSIGNED INT
by the type promotion/conversion rules I quoted.

Perhaps you could point to how and why type promotion/conversion do not
apply to this case, which - to recap - has a mixed sign pair of int args
to an arithmetic operator.  It is my understanding that 

  If the operand that has unsigned integer type has rank greater than
  or EQUAL TO the rank of the type of the other operand, the operand
  with SIGNED integer type IS CONVERTED to the type of the operand with
  UNSIGNED integer type.

That is the case here, as I parse everything I have read, which among
other things defines the type of signed and unsigned versions of an
integer type as equal.

  The rank of any unsigned integer type shall equal the rank of the
  corresponding signed integer type, if any.

Regards

PTB

Re: signed/unsigned integer conversion for right shift seems against C99 rule

[David Brown]

On 06/02/18 16:22, Liu Hao wrote:
> On 2018/2/6 23:03, Peter Breuer wrote:
>> int main() {
>>   signed   int x = 0x80000005u;
>>   unsigned int y = 0x00000002u;
>>   signed   int z = x >> y;
>>   printf("0x%0x\n", z);
>>   return 0;
>> }
>> % gcc -std=c99 test.c 
>> test.c: In function 'main':
>> test.c:6:3: warning: implicit declaration of function 'printf' [-Wimplicit-function-declaration]
>>    printf("0x%0x\n", z);
>>    ^
>> test.c:6:3: warning: incompatible implicit declaration of built-in function 'printf'
>>
>> (I'll live with that warning - just for the purpose of a clean example!)
>>
> 
> Well you could have declared the `printf()` function:
> 
>     extern int printf(const char *restrict format, ...);

Or, far better :

#include <stdio.h>

<snip>

> Clearly, the type of the operand on the right-hand side is not altered -
> it remains `unsigned int`.
> 

Equally relevantly, the left-hand side is not altered and remains
"signed int".

Basically, for operators that are at least roughly symmetrical (like *,
+, /, -, etc.), arithmetic conversions are used to make both sides into
the same types (of at least "int" size).  But for asymmetric operators,
like <<, >>, ?:, the comma operator, you get the integer promotions but
they are handled separately.

It all makes sense when you think about it.

Re: signed/unsigned integer conversion for right shift seems against

[Tadeus Prastowo]

On Tue, Feb 6, 2018 at 4:29 PM, Peter T. Breuer <ptb@inv.it.uc3m.es> wrote:
> "Also sprach Tadeus Prastowo:"
>> > int main() {
>> >   signed   int x = 0x80000005u;
>> >   unsigned int y = 0x00000002u;
>> >   signed   int z = x >> y;
>> >   printf("0x%0x\n", z);
>> >   return 0;
>> > }
>> > % ./a.out
>> > 0xe0000001
>> >   ^ SIGNED right shift
>>
>> To quote ISO-IEC 9899:1999 draft
>> (http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf) Section
>> 6.5.7 Paragraph 5: The result of E1 >> E2 is E1 right-shifted E2 bit
>> positions.  [...]  If E1 has a signed type and a negative value, the
>> resulting value is implementation-defined.
>> End quote.
>>
>> So, getting what you got should not surprise you, should it?
>
> Suitably snide, but fashionably wrong. The type of E1 is UNSIGNED INT
> by the type promotion/conversion rules I quoted.

To quote the same document's Section 6.5.7 Paragraph 3: The integer
promotions are performed on each of the operands. The type of the
result is
that of the promoted left operand.
End quote.

And to quote Section 6.3.1.1 Paragraph 2: [...] If an int can
represent all values of the original type, the value is converted to
an int; otherwise, it is converted to an unsigned int. These are
called the integer promotions. All other types are unchanged by the
integer promotions.
End quote.

So, E1 has type signed int, hasn't it?

> Regards
>
> PTB

--
Best regards,
Tadeus

Re: signed/unsigned integer conversion for right shift seems

[Peter T. Breuer]

"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.

(I'm willing to entertain ingenious interpretations of the word "type"
or "common" if that is what you are planning next).

Regards

PTB

Re: signed/unsigned integer conversion for right shift seems

[Jonathan Wakely]

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.

Re: signed/unsigned integer conversion for right shift seems against

[Peter T. Breuer]

"Also sprach Tadeus Prastowo:"
> > ...................................... The type of E1 is UNSIGNED INT
> > by the type promotion/conversion rules I quoted.
> 
> To quote the same document's Section 6.5.7 Paragraph 3: The integer
> promotions are performed on each of the operands. The type of the
> result is that of the promoted left operand.  End quote.

Yes, but no promotions are performed (I ceased reading the sentence at
that point - hit me if I do wrong). I quote

  Integer Promotions
  Integer types smaller than int are promoted when an operation is
                ^^^^^^^^^^^^^^^^
  performed on them.

The types are not "smaller than int" here. (signed int and unsigned
int respectively in x >> y). No promotions.

I'll read on ..  hmm.  I don't actually care what the result type is
(signed or unsigned - definitely int) is in this instance, as I don't
use it except to print its bits. So I don't see the final sentence
as relevant.

That promotions (of which I contend there are none; penultimate
sentence) are performed on each and all of the operands does not
disturb me.  None seem to have been performed, going by the result, so I
do not see that sentence as relevant either.

> And to quote Section 6.3.1.1 Paragraph 2: [...] If an int can
> represent all values of the original type, the value is converted to
> an int; otherwise, it is converted to an unsigned int. These are
> called the integer promotions. All other types are unchanged by the
> integer promotions.  End quote.

That is a quote for a promotion, of which none are performed. Let me 
fill out the quote (my caps)

  Integer types SMALLER THAN INT are promoted when an operation is
  performed on them. If all values of the original type can be
  represented as an int, the value of the smaller type is converted to
  an int; otherwise, it is converted to an unsigned int. Integer
  promotions are applied as part of the usual arithmetic conversions to
  certain argument expressions; operands of the unary +, -, and ~
  operators; and OPERANDS OF THE SHIFT OPERATORS. 

Not smaller than int, so no promotions.

(I'm quoting something at CMU, rather than wherever you are quoting
from,
https://wiki.sei.cmu.edu/confluence/display/c/INT02-C.+Understand+integer+conversion+rules
simply because I have to quote something and that's what google is
showing me)

We should be looking at the rules for conversions, not promotions.

> So, E1 has type signed int, hasn't it?

No promotion is applied.  I get what you saying, however, which is that
zero promotions is a promotion (!), so we should end up with int
from this nonexistent promotion of the left argument.  I agree as far
as that goes (see end of para), we should, but not by virtue of a
promotion, but by the absence of a promotion.  Everything is hunky dory
as we are supposed to promote to ints (or unsigned ints) for arithmetic
and we have that already.  I contend we are then supposed additionally
to CONVERT, not promote, by the "usual arithmetic conversion" rules.

  These rules include integer promotions, integer conversion rank, and
  the USUAL ARITHMETIC CONVERSIONS.

Can you look at that?

  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:

The best explanation I have seen so far is that  there is no WHEN
here, because the MANY does not include >>.

I have not been able to repy to what has seemed to me to be the only
valid excuse - because of the deluge.  Apologies to whoever it is.
(I think I noticed the reasoning was a bit wonky there too, but maybe
I was intoxicated when reading it).

Regards

PTB

Re: signed/unsigned integer conversion for right shift seems

[Peter T. Breuer]

"Also sprach Jonathan Wakely:"
> >   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.

Where does it say that? Your word isn't quite enough for me :-(.

By the way, this is the conclusion I have come as being the most likely
explanation by dint of certain weaselly words in the definition
of when the CONVERSION rule should be applied (my caps):

  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:

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. What is the complement of
the MANY, precisely?

I am willing to accept that it includes ">>".  Any more?  "<<", I
suppose, but the result would be insensitive to the change ..  anything
else? The first versus second/third arguments of ?:. And the
arguments of the comma operator can be left to differ in type too, not
that it makes any difference.

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

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.

Hmm ... would x/y show an effect like that? Yes. signed/unsigned
is signed, with no conversion to a joint "unsigned" type taking
place as per the conversion rule:

  If the operand that has unsigned integer type has rank greater than
  or equal to the rank of the type of the other operand, the operand
  with signed integer type is converted to the type of the operand with
  unsigned integer type.

SO / and likely % (yes?) are likely other exceptions. 

That's

   >> << (?) / % (?) , ?:

where no conversion after promotion occurs. The others are

  + - *

and for them it doesn't matter as 2s complement gives the same result
whatever.

Is there somewhere in the standard where it SAYS this?

Regards and thanks

PTB

Re: signed/unsigned integer conversion for right shift seems

[Jonathan Wakely]

On 6 February 2018 at 16:42, Peter T. Breuer <ptb@inv.it.uc3m.es> wrote:
> "Also sprach Jonathan Wakely:"
>> >   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.
>
> 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.


> By the way, this is the conclusion I have come as being the most likely
> explanation by dint of certain weaselly words in the definition
> of when the CONVERSION rule should be applied (my caps):
>
>   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:
>
> 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.


> What is the complement of
> the MANY, precisely?
>
> I am willing to accept that it includes ">>".  Any more?  "<<", I
> suppose, but the result would be insensitive to the change ..  anything
> else? The first versus second/third arguments of ?:. And the
> arguments of the comma operator can be left to differ in type too, not
> that it makes any difference.
>
>> You asked for clarification and have got your answer, but seem
>> determined to stick to your original interpretation.
>
> 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.


> Hmm ... would x/y show an effect like that? Yes. signed/unsigned
> is signed, with no conversion to a joint "unsigned" type taking
> place as per the conversion rule:
>
>   If the operand that has unsigned integer type has rank greater than
>   or equal to the rank of the type of the other operand, the operand
>   with signed integer type is converted to the type of the operand with
>   unsigned integer type.
>
> SO / and likely % (yes?) are likely other exceptions.
>
> That's
>
>    >> << (?) / % (?) , ?:
>
> where no conversion after promotion occurs. The others are
>
>   + - *
>
> and for them it doesn't matter as 2s complement gives the same result
> whatever.
>
> Is there somewhere in the standard where it SAYS this?
>
> Regards and thanks
>
> PTB
>

Re: signed/unsigned integer conversion for right shift seems

[Peter T. Breuer]

"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.

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

Perhaps also let me know what else conversion does and does not apply
to?

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"?

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.

Which of may or must not is it, since you know!

> >   If the operand that has unsigned integer type has rank greater than
> >   or equal to the rank of the type of the other operand, the operand
> >   with signed integer type is converted to the type of the operand with
> >   unsigned integer type.
> >
> > So / and likely % (yes?) are likely other exceptions.

> > Is there somewhere in the standard where it SAYS ...

Regards and thanks

PTB

Re: signed/unsigned integer conversion for right shift seems

[Jonathan Wakely]

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.

Re: signed/unsigned integer conversion for right shift seems

[Tadeus Prastowo]

On Tue, Feb 6, 2018 at 6:19 PM, Peter T. Breuer <ptb@inv.it.uc3m.es> wrote:

[...]

> 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"?

[...]

> where it says that conversion MAY NOT or MUST
> NOT be applied to the arguments of >>.

Let's assume you could do one or more conversions as you wish.  But,
certainly you know you have to follow the spec, don't you?  Now the
specification of ISO-IEC 1989:1999 says in Section 6.5.7 Paragraph 3:
"The integer promotions are performed on each of the operands. The
type of the result is that of the promoted left operand."

Now, where do you want to perform your desired conversion?  Point A:
before "The integer promotions are performed on each of the operands"?
 Point B: before "The type of the result is that of the promoted left
operand"?  Point C: after "The type of the result is that of the
promoted left operand"?  Or any other point I have not mentioned?  Or
at two or more points that I have mentioned?

Try it for yourself if you can do one or more conversions at any of
the points I have mentioned without breaking the other part of the
spec.  So, if there is no loophole, a good spec shall not mention any
other extra thing, shall it?

> Regards and thanks
>
> PTB

--
Best regards,
Tadeus

Re: signed/unsigned integer conversion for right shift seems

[Peter T. Breuer]

"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

Re: signed/unsigned integer conversion for right shift seems

[Jonathan Wakely]

On 6 February 2018 at 18:23, Peter T. Breuer <ptb@inv.it.uc3m.es> wrote:
> "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

The specification of each operator of course!

You've been pointed to them multiple times now, 6.5.5, and 6.5.6, and
6.5.7, and so on.

Are you trolling or just stubborn and unable to accept the help you asked for?

Maybe this will help:
http://en.cppreference.com/w/c/language/conversion#Usual_arithmetic_conversions
And specifically:
http://en.cppreference.com/w/c/language/operator_arithmetic#Shift_operators

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.

Re: signed/unsigned integer conversion for right shift seems

[Tadeus Prastowo]

On Tue, Feb 6, 2018 at 7:27 PM, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
> On 6 February 2018 at 18:23, Peter T. Breuer <ptb@inv.it.uc3m.es> wrote:
>> "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
>
> The specification of each operator of course!
>
> You've been pointed to them multiple times now, 6.5.5, and 6.5.6, and
> 6.5.7, and so on.
>
> Are you trolling or just stubborn and unable to accept the help you asked for?
>
> Maybe this will help:
> http://en.cppreference.com/w/c/language/conversion#Usual_arithmetic_conversions
> And specifically:
> http://en.cppreference.com/w/c/language/operator_arithmetic#Shift_operators
>
> 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.

@Peter Breuer: it seems that you are not very knowledgeable about the
internals of the C language.  Hence, I would like to invite you to
study this very good resource on the internals of the C language:
http://publications.gbdirect.co.uk/c_book/.

--
Best regards,
Tadeus

Re: signed/unsigned integer conversion for right shift seems

[Jonathan Wakely]

On 6 February 2018 at 18:37, Tadeus Prastowo wrote:
> @Peter Breuer: it seems that you are not very knowledgeable about the
> internals of the C language.  Hence, I would like to invite you to
> study this very good resource on the internals of the C language:
> http://publications.gbdirect.co.uk/c_book/.

And maybe find somewhere else to discuss it. "I don't understand the C
standard" is not a GCC problem, so doesn't belong on this mailing
list.

Re: signed/unsigned integer conversion for right shift seems

[Peter T. Breuer]

"Also sprach Tadeus Prastowo:"
> > where it says that conversion MAY NOT or MUST
> > NOT be applied to the arguments of >>.
> 
> Let's assume you could do one or more conversions as you wish. 

I do NOT WISH. I merely want to know what is specified.

> certainly you know you have to follow the spec, don't you?  Now the

No!  I had no idea!  You mean I am not allowed to invent a blue unicorn
as the result or let it kill my granny!  That is such a relief!  Thank
you :-).

> specification of ISO-IEC 1989:1999 says in Section 6.5.7 Paragraph 3:
> "The integer promotions are performed on each of the operands. The

No promotions are performed in this instance as integer promotions are
to change smaller-than-int types to int types, and we start with int
types.

> type of the result is that of the promoted left operand."

We are not interested in the type of the result.

> Now, where do you want to perform your desired conversion? 
> Point A:
> before "The integer promotions are performed on each of the operands"?

No. Integer promotions (i.e., from a type smaller than int to int)
are performed first always, and there are none here, as we start from
ints.

>  Point B: before "The type of the result is that of the promoted left
> operand"? 

That is not a "point" but a statement of the type of the result. It
says it is the same as the type of the PROMOTED (not CONVERTED)  left
operand. That is fine by me. It will be signed int in this case, as
zero promotions are applied to an int, leaving the type as signed int,
and the type of the result therfore as signed int too.

> Point C: after "The type of the result is that of the
> promoted left operand"? 

That is not a "point" either.  Perhaps you are not referring to the
operation of the compiler, and you really mean "where in the text should
we be thinking about"?

If so, there is no single "point" in the text from which deductions are
made, rather a set of statements from which we can make deductions, but
as such your "points" (sorry, no dissing intended) B and C are
irrelevant to the deduction since there has been no observation made
or alleged as to the type of the result.

> Or any other point I have not mentioned?  Or
> at two or more points that I have mentioned?

None of the above are "points" in the operation of the compiler or
the operational semantics of C. As "points" in a specification, A is
the only one that has relevance, as the type of the result (which B, C
treat of ) is not in evidence or contention. But it is vacuuous as
promotions are not performed, the operands being ints to start with.

Apologies for being literal and apparently insisting on "promotion"
meaning "change to integer type from smaller type" but I don't have
an option to understand other than what is explicitly written.  If you
mean "conversion" instead, please say.  

For conversion, the puzzle is why it is NOT done, since the rule

  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.

seems to apply, and would cause the left argument to become unsigned int
to match the right unsigned int, and the shift to become logical, not
arithmetic, which does not happen.

The best I can see is that WHEN and MANY are get-outs 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:


> Try it for yourself if you can do one or more conversions at any of

Those are points in a text, not points in the operation of a compiler
(or the runtime), so the sentence above (and below) is not well-formed.

I cannot "try it", therefore.

Or do you mean to try applying deductions at those points?  I refuted
that with "B, C are irrelevant because we do not care about the type of
the result, which makes no difference", and A does not apply (no
promotion is or can be done because the args are ints already).

> the points I have mentioned without breaking the other part of the
> spec.  So, if there is no loophole, a good spec shall not mention any
> other extra thing, shall it?

Eh? "shall not"? I am afraid I cannot parse that last sentence.

Maybe "should not"? Well, the point is that I cannot see a loophole 
allowing conversion NOT to be done EXCEPT possibly the use of WHEN and
MANY in the passage I quoted and none has been pointed to yet.

But the claim that the detailed specs of the >> operator say what's
up seem not to be justified. They don't.  They only relevant thing
is what you quoted as A,B,C above, being para 3 of the "constraints".

There is no exception to the general conversion rule I quoted:

  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.

The best one can do seems to be the WHEN and MANY I commented on above.

Anything else?

Best Regards 

PTB

Re: signed/unsigned integer conversion for right shift seems

[Peter T. Breuer]

"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

Re: signed/unsigned integer conversion for right shift seems

[Peter T. Breuer]

"Also sprach Jonathan Wakely:"
> 
> On 6 February 2018 at 18:37, Tadeus Prastowo wrote:
> > @Peter Breuer: it seems that you are not very knowledgeable about the
> > internals of the C language.  Hence, I would like to invite you to

Amusing.  Byt as the infamous author of a much used higher order
compiler compiler in C, a linear logic model checker for C, about 4
different user-driven languages that I can recall written in C, ranging
from a persistent higher order lazy functional language to a decompiler
compiler, and a mathematical logician well known as a programming
languages semanticist who has given denotational, operational and
logical semantics to many programming, machine and specification
languages, etc etc etc, "I don't think so".

Try sf.net/p/obfusc for the current snapshots of the encrypting,
ofuscating C compiler.

> > study this very good resource on the internals of the C language:
> > http://publications.gbdirect.co.uk/c_book/.
> 
> And maybe find somewhere else to discuss it. "I don't understand the C
> standard" is not a GCC problem, so doesn't belong on this mailing

Please desist from ad hominen attacks.

If you have a problem with my reasoning in any particlar instance,
please state it with specificity. 

 From the lack of valid argument, I guess the problem seems to be that
the spec has boobooed in this instance.  I would be grateful if you do
manage to find somewhere in the spec that allows the conversion thang
not to be done for >>.  

I now don't know for sure what needs to be done here.

Regards

PTB

Re: signed/unsigned integer conversion for right shift seems

[Tadeus Prastowo]

On Tue, Feb 6, 2018 at 8:43 PM, Peter T. Breuer <ptb@inv.it.uc3m.es> wrote:
> "Also sprach Jonathan Wakely:"
>>
>> On 6 February 2018 at 18:37, Tadeus Prastowo wrote:
>> > @Peter Breuer: it seems that you are not very knowledgeable about the
>> > internals of the C language.  Hence, I would like to invite you to
>
> Amusing.  Byt as the infamous author of a much used higher order
> compiler compiler in C, a linear logic model checker for C, about 4
> different user-driven languages that I can recall written in C, ranging
> from a persistent higher order lazy functional language to a decompiler
> compiler, and a mathematical logician well known as a programming
> languages semanticist who has given denotational, operational and
> logical semantics to many programming, machine and specification
> languages, etc etc etc, "I don't think so".

You mean this http://dblp.uni-trier.de/pers/hd/b/Breuer:Peter_T=  ?

[...]

>> And maybe find somewhere else to discuss it. "I don't understand the C
>> standard" is not a GCC problem, so doesn't belong on this mailing
>
> Please desist from ad hominen attacks.

Jonathan is not attacking you.  This mailing list is specific to GCC
problem, and what you are talking about is a language specification
issue.  I bet you know that you should not submit a paper to a
conference whose topic is tangential to your paper.

For C language specific issue, you should join comp.std.c to make a
defect report as you can learn from
https://groups.google.com/d/msg/comp.std.c/yIpg6gtdOoU/44GfW3-ib0YJ .

[...]

> I would be grateful if you do
> manage to find somewhere in the spec that allows the conversion thang
> not to be done for >>.

You already identified it in the previous e-mail.  The word "many".

To quote ISO-IEC 9899:1999 Section 6.3.1.8 Paragraph 1: Many operators
that expect operands of arithmetic type cause conversions and yield
result types in a similar way.  End quote.

> I now don't know for sure what needs to be done here.

Take this discussion to comp.std.c, please?

> Regards
>
> PTB

--
Best regards,
Tadeus

Re: signed/unsigned integer conversion for right shift seems

[Jonathan Wakely]

On 6 February 2018 at 19:27, Peter T. Breuer <ptb@inv.it.uc3m.es> wrote:
> "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.

Stop acting like an idiot then.

> 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?

Because it doesn't say they are applied. As I pointed out in
https://gcc.gnu.org/ml/gcc-help/2018-02/msg00031.html the other
operators *do* say the conversions are 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.

Exactly, the shift operators are not listed there, because the
conversions are not done for the shift operators.

>> 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.

Read the parenthesis! It explicitly says that for these operators,
unlike most others, arithmetic conversions are not performed!


> 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.

You are an idiot.

Re: signed/unsigned integer conversion for right shift seems

[Jonathan Wakely]

On 6 February 2018 at 20:08, Tadeus Prastowo wrote:
> Jonathan is not attacking you.

Well I am now, because he's insisting on continuing his off-topic
wanderings through the C standard.

Re: signed/unsigned integer conversion for right shift seems

[Chris Hall]

On 06/02/18 18:23, Peter T. Breuer wrote:
> 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 ...
Well, it's particularly wet outside and I have nothing better to do, so...

...with apologies for wandering off-topic...

...my copy of ISO/IEC 9899:1999 (relatively inexpensive, and a good read 
IMHO) says:

   6.3 Conversions

   Several operators convert operand values from one type to another
   automatically. ... The list in 6.3.1.8 summarizes the conversions
   performed by most ordinary operators; it is supplemented as
   required by the discussion of each operator in 6.5.

   ....

   6.3.1.8 Usual arithmetic conversions

   Many operators that expect operands of arithmetic type cause
   conversions and yield result types in a similar way.  ... This
   pattern is called the usual arithmetic conversions:

So, we have "the usual arithmetic conversions" and those apply to 
"several operators" or "many operators" or "most ordinary operators", 
but not to *all* operators.

Now, later in 6.3.1.8, having dealt with various forms of 'real' operands:

     Otherwise, the integer promotions are performed on both operands.
     Then the following rules are applied to the promoted operands:

     ....

So, "the usual arithmetic conversions" starts with "the integer 
promotions" applied to both operands, followed by a step which may then 
*convert* one or both to a common type.  [In passing, I note that 
6.3.1.8 says that "The purpose is to determine a common real type", but 
also covers determining a common 'integer' type.]

I suggest to you that (a) the "integer promotions" are a step in the 
"usual arithmetic conversions", but they are not the same, and (b) the 
"usual arithmetic conversions" are not the *universal* arithmetic 
conversions.

Going back to "6.3.1.1 Boolean, characters, and integers", I note:

   2  The following may be used in an expression wherever an int or
      unsigned int may be used:

        — An object or expression with an integer type whose
          integer conversion rank is less than the rank of int
          and unsigned int.

        — A bit-field of type _Bool, int, signed int, or
          unsigned int.

      If an int can represent all values of the original type, the
      value is converted to an int; otherwise, it is converted to
      an unsigned int. These are called the integer promotions(48).
      All other types are unchanged by the integer promotions.

   3  The integer promotions preserve value including sign. ...

So, here is the definition of the "integer promotions".  And the 
footnote (48), which you found does indeed say:

   48) 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.

I think you are reading this as:

       The integer promotions are applied, as part of the usual
       arithmetic conversions, only: to ...

I suggest that it is generally read as:

       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.

and I suggest to you that the ':' *before* "as part of the usual 
arithmetic conversions" is key, here.

Accepting that "promotions" does not imply "conversions", and as has 
been pointed out elsewhere, the definition of operators in section 6.5 
includes:

    6.5.5 Multiplicative operators
    ....

    Semantics

    3  The usual arithmetic conversions are performed on the operands.
    ....

    6.5.6 Additive operators
    ....

    Semantics

    4  If both operands have arithmetic type, the usual arithmetic
       conversions are performed on them.
    ....

    6.5.7 Bitwise shift operators
    ....

    3  Semantics

    The integer promotions are performed on each of the operands.
    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.

Noting that:

    * for '<<' and '>>' it's "promotion" *not* "conversion"

      cf: '*'. '/', '%', '+' (dyadic) and '-' (dyadic) (inter alia)
          where it is explicitly "conversion"

    * you could argue that:

        "integer promotions are performed on each of the
         operands *separately*"

      would be *crystal*.

      But there is nothing in the definition of the "integer
      promotions" that says that the promotion of one operand
      has any effect on the promotion of another.

      And it does specify that the:

        "type of the result is that of the promoted left
         operand"

      suggesting that the left and right operands may have
      different types after the "promotions".  (Remembering
      that the "usual arithmetic conversions" make the type
      of the two operands and the type of the result the
      same.)

    * and since (see above):

        "The integer promotions preserve value including sign."

      we cannot expect either argument's sign to change !

Of course, the independence of the promotions means that:

    uint64_t    s = 12 ;
    int         v = 91 ;

    v << s ;        // shifted as 'int'

    char        t = 12 ;
    short       w = 91 ;

    w << t ;        // shifted as 'int'

HTH

Chris

Re: signed/unsigned integer conversion for right shift seems

[Peter T. Breuer]

"Also sprach Jonathan Wakely:"
> >> 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.
> 
> Stop acting like an idiot then.

See above.  I and doubtless the world would appreciate it if you
refrained.  

> > 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?
> 
> Because it doesn't say they are applied. As I pointed out in

An interesting new theory, if late to the party.  You now say that the
phrase "the usual arithmetic conversions" (6.3.1.8) must be present in
the subsection relating to the operator?

Ingenious, and I'll look at that as a possibility.  Let's test.
According to the index, the phrase occurs in

   usual arithmetic conversions, 6.3.1.8 [defn], 6.5.5, 6.5.6,
   6.5.8, 6.5.9, 6.5.10, 6.5.11, 6.5.12, 6.5.15

6.5.5 = multiplicative ops (* / %)
6.5.6 = additive ops (+ -)
6.5.8 = order relations (> < <= >=)
6.5.9 = equals relns
6.5.10= bitwise &
6.5.11= bitwise ^
6.5.12= bitwise |
6.5.15= ternery op ?:

That looks plausible. 6.5.7 (>> and <<) is about all that's missing.
The rubric usually goes

  Semantics
  3 The usual arithmetic conversions are performed on the operands.

and it is not present in 6.5.7, which instead has

  Semantics
  3 The integer promotions are performed on each of the operands.

We (I!) have throughout the thread noted that there are no promotions to
be done here as both args are already int.

The possible argument put forward by someone that promotions are "a
part" of conversions and no promotions implies no conversions, I did
not find convincing (it's possible to be a not-there part of a thing
with extent, like windows in a room; a room does not _have_ to have
windows).

So this looks the strongest argument so far.  Well done.

> https://gcc.gnu.org/ml/gcc-help/2018-02/msg00031.html the other
> operators *do* say the conversions are applied.

Indeed. Strong argument, comparing the other op specs in deatil.

> >    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.
> 
> Exactly, the shift operators are not listed there, because the
> conversions are not done for the shift operators.

That doesn't work as logic - it's circumstantial and unsafe as a mode of
reasoning.  The += is also an (impure) arithmetic operator and it should
follow the same conversion rule as +, which is in your/that list.

   A compound assignment of the form E1 op = E2 differs from the simple
   assignment expression E1 = E1 [+|-] (E2) only in that the lvalue E1 is
   evaluated only once.

According to that it does borrow the semantics of + which explicitly has
the "usual arithmetic conversions" phrase, yet the phrase doesn't appear
in the text for += and the operator is not listed in the set you gave.
So according to your reasoning it should NOT have the "usual arithmetic
conversions", yet it does.

[There looks a semantic morass here, since the two imaginary appearances
of the lhs might get two different types through the rules.  It's not as
simple as foo=foo op bar, and what it boils down to exactly depends on
the lhs and the rhs, especially in case of explicit side-effects in
those.]

> >> 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.
> 
> Read the parenthesis! It explicitly says that for these operators,
> unlike most others, arithmetic conversions are not performed!

It doesn't say so explicitly (but you have - explicitly would be saying,
as you did above, "the usual arithmetic conversions are not performed").

You are saying it is not explicit but it is implicit?

Could be ...  could be not.  Hard to say.  So it is not. Implicit means
logically deducible, "implied though not directly expressed", as the
dictionary has it. I don't see it as a _necessary_ consequence, just
a possible one.

To explain, there's that finesse over whether promotions are supposed to
be a part of conversion (see somebody else in this thread, maybe even
you for all I know right now!) or not to consider, plus whether they're
lax or not in differentiating promotions from conversions.  One could
plausibly read this text as saying that promotions are performed in this
case whereas they are omitted in other cases, but in all or some or many
cases, including this, one goes on to perform the rest of the
conversions apart from the promotions.

In my opinion, however, this is corroborating evidence in favor.

But its's still just circumstantial stuff.  One has to watch out for
circumstantial evidence and not jump to conclusions (engineers make that
logical mistake, as a general rule, for lack of abstract thinking
pathways).

> > 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.
> 
> You are an idiot.

Desist from insults and attacks.  I have written an appropriate sentence
that would explicitly prohibit arithmetic conversion for >> in any
conforming compiler implementation.  Why haven't they?

Check out the "Dunning-Krueger effect" on Wikipedia.

To me, the spec looks pretty much collated from older bits of spec,
updated imperfectly. Shrug. What isn't?

I'll see if I can talk to somebody on the WG.

Regards

PTB

Re: signed/unsigned integer conversion for right shift seems

[Vincent Lefevre]

On 2018-02-06 23:49:42 +0000, Peter T. Breuer wrote:
> An interesting new theory, if late to the party.  You now say that the
> phrase "the usual arithmetic conversions" (6.3.1.8) must be present in
> the subsection relating to the operator?

This is implied by what is said at the beginning of 6.3 (which 6.3.1.8
belongs to):

  "Several operators convert operand values from one type to another
   ^^^^^^^
  automatically."

"Several", not "All". And 2 sentences later:

  "The list in 6.3.1.8 summarizes the conversions performed by
  most ordinary operators;"
  ^^^^

"most", not "all".

So, you may wonder: Where do I get more detailed information about
when this is done? The answer is at the end of the sentence:

  "it is supplemented as required by the discussion of each operator
  in 6.5."

So it says that you need to look at 6.5, which is... that:

> Ingenious, and I'll look at that as a possibility.  Let's test.
> According to the index, the phrase occurs in
> 
>    usual arithmetic conversions, 6.3.1.8 [defn], 6.5.5, 6.5.6,
>    6.5.8, 6.5.9, 6.5.10, 6.5.11, 6.5.12, 6.5.15
> 
> 6.5.5 = multiplicative ops (* / %)
> 6.5.6 = additive ops (+ -)
> 6.5.8 = order relations (> < <= >=)
> 6.5.9 = equals relns
> 6.5.10= bitwise &
> 6.5.11= bitwise ^
> 6.5.12= bitwise |
> 6.5.15= ternery op ?:
> 
> That looks plausible. 6.5.7 (>> and <<) is about all that's missing.

Now, aren't you eventually convinced?

Note that 6.3.1.8 also says: "Many operators...". "Many", not "All".

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: signed/unsigned integer conversion for right shift seems

[Peter T. Breuer]

"Also sprach Vincent Lefevre:"
> On 2018-02-06 23:49:42 +0000, Peter T. Breuer wrote:
> > An interesting new theory, if late to the party.  You now say that the
> > phrase "the usual arithmetic conversions" (6.3.1.8) must be present in
> > the subsection relating to the operator?
> 
> This is implied by what is said at the beginning of 6.3 (which 6.3.1.8
> belongs to):

Yes.  I've just been reading what seems like only the first few hundred
pages of the standard (it's not that bad - they leave big spaces between
lines) and I've got to there too.  It's before the subsections we've
been looking at, and it lays down in general terms how one should go
about constructing a semantics from the bits and bobs scattered around
the rest of the room.  That's what is required.

There is also a bit to that effect at the start of the standard where it
names SHALL and SHALL NOT as the keywords they use for must/must not.
They don't have a may/may not in keywords, but there is a confusing
kerfuffle about strictly conforming, conforming, hosted, and
freestanding that may logically amount to it, if anyone cares.

I'll quote the paragraph starting 6.3 in full (my caps):

  SEVERAL operators convert operand values from one type to another
  AUTOMATICALLY.  THIS subclause specifies the result required from SUCH
  an implicit conversion, as well as those that result from a cast
  operation (an explicit conversion).  The LIST in 6.3.1.8 summarizes
  the conversions performed by MOST ordinary operators; it is
  SUPPLEMENTED as required by the discussion of each operator in 6.5.


>   "Several operators convert operand values from one type to another
>    ^^^^^^^
>   automatically."
> 
> "Several", not "All". And 2 sentences later:

Yes, but your analysis is not complete.  First, you are right that this
sentence weasels out of being prescriptive with "several", but it's not
a prescriptive sentence in the first place, just a descriptive one, so
we shouldn't be looking to it for instruction.  It's really intended as
a warning that we should be prepared to see stuff about CONVERSION
coming up, and (1) the AUTOMATICALLY that we will see does not refer to
the application of THESE instructions, but to the compiletime process
and the absence of an EXPLICIT instruction in source code (as the next
sentence further expounds).

"automatically = not explicit" is the thing  it tells us there.

The NEXT sentence tells us also that "explicit = cast".  So we know that
(1) autmatically/implicit are words to be applied for "no cast", and (2)
explicit is a word that means "cast". 

That's all there is of substance in the first two sentences.

The final sentence is a killer that puts aside the hint of weaselity in
the first sentence by telling us exactly how we are to figure out
conversions.  We are first to look at a list in 6.3.1.8 to see what is
up, but we are to override that or fill in undefined areas with
specifics from 6.5.  That's all.  Nothing else, and so this IS
prescriptive.

There's stuff I've left out like the "SUCH" leaving it open that there
are implicit conversions that are not automatic. Somebody bear that
in mind (not me!). But I'll go with automatic implies implicit, and
try not to lean on the converse.

>   "The list in 6.3.1.8 summarizes the conversions performed by
>   most ordinary operators;"
>   ^^^^
> 
> "most", not "all".

Yes, but that's meaningless if they're going to leave it at that,
and they don't.

> So, you may wonder: Where do I get more detailed information about
> when this is done? The answer is at the end of the sentence:
> 
>   "it is supplemented as required by the discussion of each operator
>   in 6.5."
> 
> So it says that you need to look at 6.5, which is... that:

No.  It says to look at the list, which applies in the absence of being
countermanded (or supplemented) in 6.5.  The "most" is to acknowledge
the list possibly not being prescriptive because of that exception.  We
know that because no other means of constructing the semantics is given.
That's it.  All.  No more.  It's the list or the details in 6.5 or
nothing, zilch, fin. 

> > Ingenious, and I'll look at that as a possibility.  Let's test.
> > According to the index, the phrase occurs in
> > 
> >    usual arithmetic conversions, 6.3.1.8 [defn], 6.5.5, 6.5.6,
> >    6.5.8, 6.5.9, 6.5.10, 6.5.11, 6.5.12, 6.5.15
> > 
> > 6.5.5 = multiplicative ops (* / %)
> > 6.5.6 = additive ops (+ -)
> > 6.5.8 = order relations (> < <= >=)
> > 6.5.9 = equals relns
> > 6.5.10= bitwise &
> > 6.5.11= bitwise ^
> > 6.5.12= bitwise |
> > 6.5.15= ternery op ?:
> > 
> > That looks plausible. 6.5.7 (>> and <<) is about all that's missing.
> 
> Now, aren't you eventually convinced?

Of what? What is required is REASONING. It has not been presented
so there has been nothing to be convinced of.

> Note that 6.3.1.8 also says: "Many operators...". "Many", not "All".

Umm ..  what is 6.3.1.8?  Oh, that's the list.  It doesn't matter what
it tries to say in 6.3.1.8 because we already have it from the paragraph
I quoted above from the start of 6.3 that the list in 6.3.1.8 is
prescriptive, except as it is countermanded and supplemented in 6.5.

And "many operators" would be meaningless, so I think we should take
what they have written down as pretty much it.

That's useful to me.  I had given the same generic compiler construction
for * /, but a different one for % (because it's doable as (a/b)* b -
a), and so I'll join those up and treat them as a single group (note to
self :-).

I also had + - treated by the same generic construction, so that's
right.

I had order and equals relations grouped together so I'll examine that
to see if there's a difference worth mentioning and maybe separate
order and equals if so (note to self).

I had the bitwise logical operations and >> << treated by the same
generic construction, so I'll look at those and see if they need
separate treatment (note ...)

The ternery op was treated separately anyway, just because 3 != 2.

Complement and negate unaries need looking at too.

OK, plenty to do before lunch.

Regards

PTB

Re: signed/unsigned integer conversion for right shift seems

[Peter T. Breuer]

"Also sprach Jonathan Wakely:"
> 
> On 6 February 2018 at 20:08, Tadeus Prastowo wrote:
> > Jonathan is not attacking you.
> 
> Well I am now, because he's insisting on continuing his off-topic
> wanderings through the C standard.

The question is if gcc is following the C standard.

You are counselled not to do the attacking thing, unless you would like
to be e-sat on and e-fingered by the e-police, or just generally
villified and derided as that e-wit throughout the Internet and the
e-iverse in general.

To summarize what we know:

6.1.3.8 of many C standards contains a list of for what operators
conversions should be applied "automatically", which means "without a
cast", which means "implicitly".  That list is prescriptive except
inasmuch as it is countermanded and/or overridden by the one-by-one
details of the operators in 6.5.  There is nothing else that applies, as
the authority at the start of section 6.1 says.

That is all.

In the case that I used to exemplify the situation, there are no
promotions (ints are already the args) and there are no conversions
because >> is not listed for conversions in 6.1.3.8 AND its own
paragraph in 6.5 does not say "conversions" (it says "promotions"
instead) AND 6.1 says that is all.

Done.

Exercise - try it with long long int in place of int.

Thank you for your contribution.

Regards

PTB

Re: signed/unsigned integer conversion for right shift seems

[David Brown]

On 07/02/18 10:59, Peter T. Breuer wrote:
> "Also sprach Jonathan Wakely:"
>>
>> On 6 February 2018 at 20:08, Tadeus Prastowo wrote:
>>> Jonathan is not attacking you.
>>
>> Well I am now, because he's insisting on continuing his off-topic
>> wanderings through the C standard.
> 
> The question is if gcc is following the C standard.

It is.  This has been explained to you, patiently and repeatedly, by
several people here.  You have been directed to the standards, and to
reference sites that are known to be accurate and reliable
(http://en.cppreference.com).  You have been requested, repeatedly and
politely, to take this discussion to an appropriate place if you want to
continue it.

No one is going to claim that gcc is perfect.  No one is going to claim
that the C standards are always clear and easy to follow.  But in this
case, the standards are unambiguous and gcc follows them correctly.  As
I see it, you have three sensible choices.

1. You can trust the experts on the matter.  (I don't know the
qualifications of other people in this thread, but Jonathan is/was
secretary of the C++ ISO working group.  If he says something about C,
C++ or gcc, you can be confident that it is correct.)

2. You can study the standards, and maybe you will understand it yourself.

3. You can ask /politely/ in an appropriate place, such as the
comp.std.c or comp.lang.c newsgroups.  Reading and listening to people,
rather than arguing, would help.

> 
> You are counselled not to do the attacking thing, unless you would like
> to be e-sat on and e-fingered by the e-police, or just generally
> villified and derided as that e-wit throughout the Internet and the
> e-iverse in general.

Patronising will not help your case.  Remember that in this mailing list
- in the context of gcc - Jonathan commands enormous respect, earned
from years of work on the compiler, libraries, and the languages
themselves.  You - in the context of this mailing list - are a nobody.
(I am not a gcc developer either - but I have no illusions of grandeur.)
 Be in no doubt that your writing here makes you look rude, ignorant,
and more like a spoiled teenager than a serious developer.

> 
> To summarize what we know:
> 
> 6.1.3.8 of many C standards contains a list of for what operators
> conversions should be applied "automatically", which means "without a
> cast", which means "implicitly".  That list is prescriptive except
> inasmuch as it is countermanded and/or overridden by the one-by-one
> details of the operators in 6.5.  There is nothing else that applies, as
> the authority at the start of section 6.1 says.

Section 6.3.1.8p1 describes the "usual arithmetic conversions" that
apply to many (not all) operators in order to determine a common real
type for the operands and result.  When there are no floating point
types involved, this includes performing "integer promotions" to both
operands individually, before finding the common type.

"Integer promotion" is always done for a /single/ object or expression,
and is distinct from finding a common type for two operands.  It is
described in 6.3.1.1p2.

These paragraphs describe how specific types of automatic conversions
are to be done - they do not say /when/ they are to be applied.

Details of which automatic conversions are applied to the operands of
different operators are given in 6.5.  For example, in 6.5.5p3 for
"Multiplicative operators" it says "The usual arithmetic conversions are
performed on the operands".  And in 6.5.7p3 for "Bitwise shift
operators", it says "The integer promotions are performed on each of the
operands".

/That/ is all you need.


Hopefully, that will cover everything.  If you have any more questions
on the subject, ask in the right place.  If you think the standards are
unclear, complain to the C standards committee and ask for an
improvement in the wording.  If you think the compiler is wrong, file a
bug report (it will be closed as invalid).

Other than that, you might like to post an apology and a thank-you to
the people in this list that have helped you.

Re: signed/unsigned integer conversion for right shift seems

[Jonathan Wakely]

On 7 February 2018 at 16:34, Peter T. Breuer wrote:
> Dear David et al
>
>
> I'll repeat the paragraph from my summary this morning.

Please don't, your sophistry is still off-topic. Repeating it doesn't
make it any less so.

The insight you finally gave me credit for wasn't even mine
originally, but as I'd also said in an earlier mail, you aren't paying
attention. Too busy stroking yourself for being so clever.

Now please go away, you tedious fart.

Re: signed/unsigned integer conversion for right shift seems

[Peter T. Breuer]

"Also sprach Jonathan Wakely:"
> 
> On 7 February 2018 at 16:34, Peter T. Breuer wrote:
> > I'll repeat the paragraph from my summary this morning.
> 
> Please don't, your sophistry is still off-topic. Repeating it doesn't

Kindly explain why explaining is off-topic in your opinion.

> make it any less so.

 Sophistry \Soph"ist*ry\, n. [OE. sophistrie, OF. sophisterie.]
 The art or process of reasoning; logic. [Obs.] [1913 Webster]

Correct. I am exact, which is the minimum anyone can be.

> The insight you finally gave me credit for wasn't even mine

It is.  Kindly point to somebody who says it before you?  For example, I
see from you Tue 16.45:

  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.

which is not it. Either you still don't get what IT is, or ... I don't
know. To give you the clue, here is my response (my caps) at 20.11:

  I see nothing that says that conversions should NOT be applied to
  their operators.

Got it yet? Here is where you did give the clue. I'll help again with
caps:

  > 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?  
  > 
  > BECAUSE it doesn't say they are applied. As I pointed out in  

Get it? You finally exposed your REASONING, for the very first and only
time.

That single instance of displayed reasoning was enough for me.

You could have saved yourself you had merely gone to that ordinary
length beforehand, but no.

> originally, but as I'd also said in an earlier mail, you aren't paying
> attention. Too busy stroking yourself for being so clever.

I am not clever! Just ordinary! 

> Now please go away, you tedious fart.

Pot.


PTB

Re: signed/unsigned integer conversion for right shift seems

[Jonathan Wakely]

On 7 February 2018 at 17:25, Peter T. Breuer <ptb@inv.it.uc3m.es> wrote:
> "Also sprach Jonathan Wakely:"
>>
>> On 7 February 2018 at 16:34, Peter T. Breuer wrote:
>> > I'll repeat the paragraph from my summary this morning.
>>
>> Please don't, your sophistry is still off-topic. Repeating it doesn't
>
> Kindly explain why explaining is off-topic in your opinion.
>
>> make it any less so.
>
>  Sophistry \Soph"ist*ry\, n. [OE. sophistrie, OF. sophisterie.]
>  The art or process of reasoning; logic. [Obs.] [1913 Webster]
>
> Correct. I am exact, which is the minimum anyone can be.

I prefer this from https://www.merriam-webster.com/dictionary/sophistry
Thus sophist (which comes from Greek sophist?s, meaning "wise man" or
"expert") earned a negative connotation as "a captious or fallacious
reasoner." Sophistry is reasoning that seems plausible on a
superficial level but is actually unsound, or reasoning that is used
to deceive.

>
>> The insight you finally gave me credit for wasn't even mine
>
> It is.  Kindly point to somebody who says it before you?

https://gcc.gnu.org/ml/gcc-help/2018-02/msg00019.html
https://gcc.gnu.org/ml/gcc-help/2018-02/msg00020.html

You may claim it wasn't precise enough for you, but that's your
problem for being an idiot. Nobody here is under any obligation to
provide you with a formal education in the C standard. You were given
the answers, and several clues how to interpret the standard if you
cared to. You chose to ignore or misinterpret them, because they
didn't suit you. Call that exactness if you wish, I call it arrogance
and pissiness.

Re: signed/unsigned integer conversion for right shift seems

[Tadeus Prastowo]

On Wed, Feb 7, 2018 at 6:25 PM, Peter T. Breuer <ptb@inv.it.uc3m.es> wrote:
> "Also sprach Jonathan Wakely:"
>>
>> On 7 February 2018 at 16:34, Peter T. Breuer wrote:
>> > I'll repeat the paragraph from my summary this morning.
>>
>> Please don't, your sophistry is still off-topic. Repeating it doesn't
>
> Kindly explain why explaining is off-topic in your opinion.
>
>> make it any less so.
>
>  Sophistry \Soph"ist*ry\, n. [OE. sophistrie, OF. sophisterie.]
>  The art or process of reasoning; logic. [Obs.] [1913 Webster]
>
> Correct. I am exact, which is the minimum anyone can be.

Good.  Now since you claimed that you were a mathematical logician in
one of the previous e-mails, I will let you know as a newcomer in this
mailing list that the set of axioms in this mailing list that you keep
posting to includes the proposition that said that "a discussion on
the C language issue is disallowed", another proposition that said
that "if a discussion is about a C language issue, then the discussion
is off-topic", and another proposition that said that "an off-topic
discussion shall not be discussed any longer."

So, can't you stop now, please, you who claimed to be
http://dblp.uni-trier.de/pers/hd/b/Breuer:Peter_T= ?

--
Best regards,
Tadeus

Re: signed/unsigned integer conversion for right shift seems

[Jonathan Wakely]

On 7 February 2018 at 17:25, Peter T. Breuer <ptb@inv.it.uc3m.es> wrote:
> "Also sprach Jonathan Wakely:"
>>
>> On 7 February 2018 at 16:34, Peter T. Breuer wrote:
>> > I'll repeat the paragraph from my summary this morning.
>>
>> Please don't, your sophistry is still off-topic. Repeating it doesn't
>
> Kindly explain why explaining is off-topic in your opinion.
>
>> make it any less so.
>
>  Sophistry \Soph"ist*ry\, n. [OE. sophistrie, OF. sophisterie.]
>  The art or process of reasoning; logic. [Obs.] [1913 Webster]
>
> Correct. I am exact, which is the minimum anyone can be.
>
>> The insight you finally gave me credit for wasn't even mine
>
> It is.  Kindly point to somebody who says it before you?  For example, I
> see from you Tue 16.45:

That was the first time I said it, in:
https://gcc.gnu.org/ml/gcc-help/2018-02/msg00029.html
Then again in:
https://gcc.gnu.org/ml/gcc-help/2018-02/msg00031.html
Then again in:
https://gcc.gnu.org/ml/gcc-help/2018-02/msg00034.html
Then again, referring you to an earlier post, in:
https://gcc.gnu.org/ml/gcc-help/2018-02/msg00041.html

Only then did you finally get your head out of your arse, saying "An
interesting new theory, if late to the party."

It was neither new nor late, you just refused to see what was being
said. Maybe if you spent less time expecting formal logic in response
to drivel you'd be able to communicate like a functioning human.

Now please, piss off.

Re: signed/unsigned integer conversion for right shift seems

[Peter T. Breuer]

"Also sprach Jonathan Wakely:"
> > Correct. I am exact, which is the minimum anyone can be.
> 
> I prefer this from https://www.merriam-webster.com/dictionary/sophistry
> Thus sophist (which comes from Greek sophist?s, meaning "wise man" or
> "expert") earned a negative connotation as "a captious or fallacious

It is ambiguous in the sense that both it and its opposite are possible
dictionary meanings, a rare distinction.  Your choice was number 2 in
the usual dictionary list.  I preferred number 1 both on the basis of
accuracy in this instance and popularity as per the dictionary ordering.

I could care less ;)

It illustrated that you should be more careful, so I allowed it.

> reasoner." Sophistry is reasoning that seems plausible on a
> superficial level but is actually unsound, or reasoning that is used
> to deceive.

Unfortunately for your likely intention, my reasoning is both deep and
correct and it is on display preciely in order that you may be able to
take issue with it at any point in it.

Please go ahead.

Otherwise I'll take that as childish meaningless nonsense and be happy.

> >> The insight you finally gave me credit for wasn't even mine
> > It is.  Kindly point to somebody who says it before you?
> https://gcc.gnu.org/ml/gcc-help/2018-02/msg00019.html

(1) That doesn't work as a method of answering.  You are supposed to
    quote the precise passage you mean and 
(2) explicitly state the reasoning that forms your opinion of it

Otherwise you are being ambiguous.  I'll quote 19 in its entirety,
noting beforehand that it does not say it. My (1):

  See the definition of "usual arithmetic conversions" in the text of the
  standard and note that they are not applied to bitwise shift arguments
  (they undergo integer promotions individually).

Where in there do you see it said?  I don't.  Let me remind you that the
single keyword was BECAUSE. 

Here's my (2): He does not reveal any reasoning, so that is empty of
content because we require reasoning to connect the dots  between the
standard and the conclusion (no conversions).

To explain further the standard contains many statements, none of them
is that conversions shall not be applied in this case, so one requires
reasoning to connect things in the standard with the conclusion one
wants.  He does not provide it.

You did, with that ONE WORD ("because"), for the first time. Do you see
a "because" or a "therefore" or a "since" or an "as" or a "whence" etc.
in msg 19?

That single word "because" was enough of a clue for me to construct the
whole probable chain of reasoning that you couldn't be arsed to express.

How do you think people can follow your reasoning if you do not
enunciate it?

That "because" was enough on its own to start me looking through the
whole standard word by word first for the DATA (such as that paraphrased
in msg 19) that might permit the logic chain to be constructed on top of
it, and secondly for the RULES OF DEDUCTION that would form the body of
the logic chain.

Do you get it now?

6.1 provides the rule

   (8.3.18 =/> ~p /\ 6.5 =/> ~p) => p

That form of reasoning would be invalid without its authority. Invalid
reasoning is invalid reasoning, full stop. Don't explain your rule
of deduction and what authorizes it and you are reasoning invalidly.

If you cannot read that, or for some other reason you find your mind
just "skips over it" witout taking it in, please LET ME KNOW and I will
rephrase in less formal language.  It is not unusual for people to be
"symbol-blind".  I'm phrasing it in a form that I natively expect you to
be familiar and comfortable with, but if I am wrong with that guess,
you'll have to tell me.  It's no skin one way or another.

> https://gcc.gnu.org/ml/gcc-help/2018-02/msg00020.html

I'm not going to bother because your credibility is already zero with
these things, having shown so many times (e.g.  19 above) that you fail
to get it.

Oh logicks, count thy number that I have written, proved complete, and
sound.

> You may claim it wasn't precise enough for you, but that's your

I have no idea or opinion on preciseness. It is simply irrelevant,

> problem for being an idiot. Nobody here is under any obligation to

Reading anything I write should tell you and anyone what is really up.

I can't make you see what you appear not to be able to see although the
huge majority of people in the world can ...  All I can comfort you with
is that it is a recognized generic problem of engineers. And
administrators.  Also poor lawyers. Actually, poor anything.


Yea! It's common! Unfortunately, no cure is available, but it
begins with the realization that there may be something there that
you are missing. Treat it like one of those aliens you can only see if
you don't look straight at them ;).

> provide you with a formal education in the C standard. You were given

Nobody is doing so and nobody is obliged to do anything, except that it
is a simple and universal courtesy from and to human beings to explain
their reasoning.

To put it another less charitable way, people who can't see or explain
their reasoning are subhuman nazis, and so one aims to show one is not
by always showing ones reasoning.  That will leave it vunerable to
challenge and the idea is precisely that.

> the answers, and several clues how to interpret the standard if you

You still don't get it, but we know that. It is YOU that I am
interpreting, not the standard. YOU need to show YOUR reasoning.

Only that enables its worth to be judged, and that is the common
courtesy that one human being leaves another.

> cared to. You chose to ignore or misinterpret them, because they

I have done nothing of the kind. 

It seems to me that when I have asked you to show

   "What, specifically, do you see in 6.5.7 that allows the conversion
   specified by the general rule of conversions ... NOT to be applied?"

that YOU are misinterpreting that as a request to be pointed at WHERE 
in the standard is the BASIS for a deduction that conversion may not
be applied (in fact must not, as it turns out).

I did not ask that.

I asked for WHAT IS THE LOGICAL RULE. Nothing else can be of interest.

I was expecting you to point at what in the end turned out to be 6.3
first paragraph final sentence, where it announces the DEDUCTION RULE
that says it's either in 6.3.18 or in 6.5 or it is not allowed.

I put it down to your blindness to the fact that your own and the
standard's logic exists and are things. In the standard's case, the
rules of the logic have to be written down somewhere, because that
is what standards do. 

You kept on not referring me to it and claiming that you had. Indeed,
you gave no reasoning at all for your statements, thus saying
absolutely nothing.

It is a problem of "level".

> didn't suit you. Call that exactness if you wish, I call it arrogance
> and pissiness.

I call it normal, ordinary, everyday stuff, that every human being
needs and does in order to do their own stuff in a coherent fashion.  To
be human, you show you have the self-knowledge to be able to explain
your own mental workings. It's only machines (well, and animals) that
can't.

I hope that the penny is if not dropped, on it way into the slot.
Remember that ONE WORD ("because") was enough for me, and please
reflect.

Regards

PTB

Re: signed/unsigned integer conversion for right shift seems

[Jonathan Wakely]

On 7 February 2018 at 18:32, Peter T. Breuer wrote:
> "Also sprach Jonathan Wakely:"
>> > Correct. I am exact, which is the minimum anyone can be.
>>
>> I prefer this from https://www.merriam-webster.com/dictionary/sophistry
>> Thus sophist (which comes from Greek sophist?s, meaning "wise man" or
>> "expert") earned a negative connotation as "a captious or fallacious
>
> It is ambiguous in the sense that both it and its opposite are possible
> dictionary meanings, a rare distinction.  Your choice was number 2 in
> the usual dictionary list.  I preferred number 1 both on the basis of
> accuracy in this instance and popularity as per the dictionary ordering.
>
> I could care less ;)
>
> It illustrated that you should be more careful, so I allowed it.
>
>> reasoner." Sophistry is reasoning that seems plausible on a
>> superficial level but is actually unsound, or reasoning that is used
>> to deceive.
>
> Unfortunately for your likely intention, my reasoning is both deep and
> correct and it is on display preciely in order that you may be able to
> take issue with it at any point in it.

You are https://www.reddit.com/r/iamverysmart/ and I claim my five pounds.

Re: signed/unsigned integer conversion for right shift seems

[Peter T. Breuer]

"Also sprach Tadeus Prastowo:"
> Good.  Now since you claimed that you were a mathematical logician in
> one of the previous e-mails, I will let you know as a newcomer in this
> mailing list that the set of axioms in this mailing list that you keep
> posting to includes the proposition that said that "a discussion on
> the C language issue is disallowed", another proposition that said

I am not discussing the C language, let alone any "issue" you may or
may not have with it. 

You see no opinion on C from me at all.  I have not expressed whether or
not I think the gcc computed goto is a good idea, for example (I don't
like it but have never used it, and it surely has its place - it's
semantically horrible, however, and gcc statements as expressions
is also bad).

It was quite a specific question: is gcc right in this instance.

If you thought it was off topic for gcc-help, I would have been glad to
ask elsewhere, at your suggestion.

For the rest, I merely reply to what is emailed to me.

My best guess from the weird replies is indeed that I've overtaxed the
natives, unwittingly, and I apologise for that. 

I recall now, belatedly, that the "help" newsgroups for an area are
generally for dispensing somewhat platitudinous advice to newbies.  

That explains a lot.

> that "if a discussion is about a C language issue, then the discussion
> is off-topic", and another proposition that said that "an off-topic

What "C language issue" do you claim this is about? We want to know
if gcc is right, since on the face of it it seemed to contradict the
standard's pithy words on conversions.

The correct response was "no it doesn't because 6.5 says that
conversions are not applied for >> and 6.3.18 does not list
 >> among what things conversion is applied to and 6.1 says that nothing
else than 6.5 defaulting to 6.3.18 is allowed".

Fin.

Instead, a hail of rubbish ensued, to which I conscienciously replied,
nicely pointing out what was wrong with it, because I am a nice and
kind person, and when somebody writes nonsense, I am nice and kind
enough to correct them, less they continue to do so and hurt
themselves.

I should have been clever enough to realise I was talking to the
janitor.

> discussion shall not be discussed any longer."

Nobody is discussing anything. The correct statement is as above:

  "signed >> unsigned"

  in gcc should not convert to

  "unsigned >> unsigned"

  even though that IS an "automatic" conversion in the standard because
  $6.5 says that conversions are not applied for >> and $6.3.18 does not
  list >> among things conversion is applied to and $6.1 says that
  nothing else than $6.5 defaulting to $6.3.18 SHALL BE allowed

QED.

It should not have been hard for you.

> So, can't you stop now, please, you who claimed to be
> http://dblp.uni-trier.de/pers/hd/b/Breuer:Peter_T= ?

I did not claim it, and I insist you spell correctly, if at all.

PTB

Re: signed/unsigned integer conversion for right shift seems against

[Tadeus Prastowo]

On Tue, Feb 6, 2018 at 5:17 PM, Peter T. Breuer <ptb@inv.it.uc3m.es> wrote:
> "Also sprach Tadeus Prastowo:"
>> > ...................................... The type of E1 is UNSIGNED INT
>> > by the type promotion/conversion rules I quoted.
>>
>> To quote the same document's Section 6.5.7 Paragraph 3: The integer
>> promotions are performed on each of the operands. The type of the
>> result is that of the promoted left operand.  End quote.

[...]

> So I don't see the final sentence
> as relevant.

It is relevant.  See below.

> (I'm quoting something at CMU, rather than wherever you are quoting
> from,
> https://wiki.sei.cmu.edu/confluence/display/c/INT02-C.+Understand+integer+conversion+rules
> simply because I have to quote something and that's what google is
> showing me)

Which "standard" are you going to follow?  CMU's one, which you
quoted, or the one followed by GCC, which is the ISO-IEC 9899:1999,
which I quoted and whose link I gave you already in my first response
to you?

> We should be looking at the rules for conversions, not promotions.
>
>> So, E1 has type signed int, hasn't it?

[...]

> I agree as far
> as that goes (see end of para)

[...]

> I contend we are then supposed additionally
> to CONVERT, not promote, by the "usual arithmetic conversion" rules.

So, by the second sentence of the ISO-IEC paragraph at the top of this
e-mail, the second sentence that you said irrelevant, you know that E1
>> E2 has the type of E1 after integer promotion.  Now you contend
that there must be a conversion.  One possibility is by the assignment
operator.  But, as you can see, the type of the expression E1 >> E2
already matches the type of the left operand of the assignment
operator.  So, no conversion takes place.

If you still argue that a conversion must take place, now it is your
turn to quote the ISO-IEC 9899:1999 document to support your argument.

> Regards
>
> PTB

--
Best regards,
Tadeus