* signed/unsigned integer conversion for right shift seems against C99 rule
@ 2018-02-06 15:03 Peter Breuer
2018-02-06 15:21 ` Tadeus Prastowo
` (2 more replies)
0 siblings, 3 replies; 40+ messages in thread
From: Peter Breuer @ 2018-02-06 15:03 UTC (permalink / raw)
To: gcc-help
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
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: signed/unsigned integer conversion for right shift seems against C99 rule
2018-02-06 15:03 signed/unsigned integer conversion for right shift seems against C99 rule Peter Breuer
@ 2018-02-06 15:21 ` Tadeus Prastowo
2018-02-06 15:29 ` signed/unsigned integer conversion for right shift seems against Peter T. Breuer
2018-02-06 15:22 ` signed/unsigned integer conversion for right shift seems against C99 rule Liu Hao
2018-02-06 15:22 ` signed/unsigned integer conversion for right shift seems against C99 rule Alexander Monakov
2 siblings, 1 reply; 40+ messages in thread
From: Tadeus Prastowo @ 2018-02-06 15:21 UTC (permalink / raw)
To: Peter.T.Breuer; +Cc: gcc-help
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
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: signed/unsigned integer conversion for right shift seems against
2018-02-06 15:21 ` Tadeus Prastowo
@ 2018-02-06 15:29 ` Peter T. Breuer
2018-02-06 15:38 ` Tadeus Prastowo
0 siblings, 1 reply; 40+ messages in thread
From: Peter T. Breuer @ 2018-02-06 15:29 UTC (permalink / raw)
To: Tadeus Prastowo; +Cc: Peter.T.Breuer, gcc-help
"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
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: signed/unsigned integer conversion for right shift seems against
2018-02-06 15:29 ` signed/unsigned integer conversion for right shift seems against Peter T. Breuer
@ 2018-02-06 15:38 ` Tadeus Prastowo
2018-02-06 16:17 ` Peter T. Breuer
0 siblings, 1 reply; 40+ messages in thread
From: Tadeus Prastowo @ 2018-02-06 15:38 UTC (permalink / raw)
To: ptb; +Cc: Peter.T.Breuer, gcc-help
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
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: signed/unsigned integer conversion for right shift seems against
2018-02-06 15:38 ` Tadeus Prastowo
@ 2018-02-06 16:17 ` Peter T. Breuer
0 siblings, 0 replies; 40+ messages in thread
From: Peter T. Breuer @ 2018-02-06 16:17 UTC (permalink / raw)
To: Tadeus Prastowo; +Cc: ptb, Peter.T.Breuer, gcc-help
"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
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: signed/unsigned integer conversion for right shift seems against C99 rule
2018-02-06 15:03 signed/unsigned integer conversion for right shift seems against C99 rule Peter Breuer
2018-02-06 15:21 ` Tadeus Prastowo
@ 2018-02-06 15:22 ` Liu Hao
2018-02-06 15:31 ` David Brown
2018-02-06 15:50 ` signed/unsigned integer conversion for right shift seems Peter T. Breuer
2018-02-06 15:22 ` signed/unsigned integer conversion for right shift seems against C99 rule Alexander Monakov
2 siblings, 2 replies; 40+ messages in thread
From: Liu Hao @ 2018-02-06 15:22 UTC (permalink / raw)
To: Peter.T.Breuer, gcc-help
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
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: signed/unsigned integer conversion for right shift seems against C99 rule
2018-02-06 15:22 ` signed/unsigned integer conversion for right shift seems against C99 rule Liu Hao
@ 2018-02-06 15:31 ` David Brown
2018-02-06 15:50 ` signed/unsigned integer conversion for right shift seems Peter T. Breuer
1 sibling, 0 replies; 40+ messages in thread
From: David Brown @ 2018-02-06 15:31 UTC (permalink / raw)
To: Liu Hao, Peter.T.Breuer, gcc-help
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.
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: signed/unsigned integer conversion for right shift seems
2018-02-06 15:22 ` signed/unsigned integer conversion for right shift seems against C99 rule Liu Hao
2018-02-06 15:31 ` David Brown
@ 2018-02-06 15:50 ` Peter T. Breuer
2018-02-06 15:57 ` Jonathan Wakely
1 sibling, 1 reply; 40+ messages in thread
From: Peter T. Breuer @ 2018-02-06 15:50 UTC (permalink / raw)
To: Liu Hao; +Cc: Peter.T.Breuer, gcc-help
"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
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: signed/unsigned integer conversion for right shift seems
2018-02-06 15:50 ` signed/unsigned integer conversion for right shift seems Peter T. Breuer
@ 2018-02-06 15:57 ` Jonathan Wakely
2018-02-06 16:42 ` Peter T. Breuer
0 siblings, 1 reply; 40+ messages in thread
From: Jonathan Wakely @ 2018-02-06 15:57 UTC (permalink / raw)
To: ptb; +Cc: Liu Hao, Peter.T.Breuer, gcc-help
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.
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: signed/unsigned integer conversion for right shift seems
2018-02-06 15:57 ` Jonathan Wakely
@ 2018-02-06 16:42 ` Peter T. Breuer
2018-02-06 16:45 ` Jonathan Wakely
0 siblings, 1 reply; 40+ messages in thread
From: Peter T. Breuer @ 2018-02-06 16:42 UTC (permalink / raw)
To: Jonathan Wakely; +Cc: ptb, Liu Hao, Peter.T.Breuer, gcc-help
"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
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: signed/unsigned integer conversion for right shift seems
2018-02-06 16:42 ` Peter T. Breuer
@ 2018-02-06 16:45 ` Jonathan Wakely
2018-02-06 17:19 ` Peter T. Breuer
0 siblings, 1 reply; 40+ messages in thread
From: Jonathan Wakely @ 2018-02-06 16:45 UTC (permalink / raw)
To: ptb; +Cc: Liu Hao, Peter.T.Breuer, gcc-help
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
>
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: signed/unsigned integer conversion for right shift seems
2018-02-06 16:45 ` Jonathan Wakely
@ 2018-02-06 17:19 ` Peter T. Breuer
2018-02-06 17:35 ` Jonathan Wakely
2018-02-06 17:44 ` Tadeus Prastowo
0 siblings, 2 replies; 40+ messages in thread
From: Peter T. Breuer @ 2018-02-06 17:19 UTC (permalink / raw)
To: Jonathan Wakely; +Cc: ptb, Liu Hao, Peter.T.Breuer, gcc-help
"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
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: signed/unsigned integer conversion for right shift seems
2018-02-06 17:19 ` Peter T. Breuer
@ 2018-02-06 17:35 ` Jonathan Wakely
2018-02-06 18:23 ` Peter T. Breuer
2018-02-06 17:44 ` Tadeus Prastowo
1 sibling, 1 reply; 40+ messages in thread
From: Jonathan Wakely @ 2018-02-06 17:35 UTC (permalink / raw)
To: Peter Breuer; +Cc: Liu Hao, Peter Breuer, gcc-help
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.
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: signed/unsigned integer conversion for right shift seems
2018-02-06 17:35 ` Jonathan Wakely
@ 2018-02-06 18:23 ` Peter T. Breuer
2018-02-06 18:27 ` Jonathan Wakely
2018-02-06 21:18 ` Chris Hall
0 siblings, 2 replies; 40+ messages in thread
From: Peter T. Breuer @ 2018-02-06 18:23 UTC (permalink / raw)
To: Jonathan Wakely; +Cc: Peter Breuer, Liu Hao, Peter Breuer, gcc-help
"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
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: signed/unsigned integer conversion for right shift seems
2018-02-06 18:23 ` Peter T. Breuer
@ 2018-02-06 18:27 ` Jonathan Wakely
2018-02-06 18:37 ` Tadeus Prastowo
2018-02-06 19:28 ` Peter T. Breuer
2018-02-06 21:18 ` Chris Hall
1 sibling, 2 replies; 40+ messages in thread
From: Jonathan Wakely @ 2018-02-06 18:27 UTC (permalink / raw)
To: Peter Breuer; +Cc: Liu Hao, Peter Breuer, gcc-help
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.
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: signed/unsigned integer conversion for right shift seems
2018-02-06 18:27 ` Jonathan Wakely
@ 2018-02-06 18:37 ` Tadeus Prastowo
2018-02-06 18:47 ` Jonathan Wakely
2018-02-06 19:28 ` Peter T. Breuer
1 sibling, 1 reply; 40+ messages in thread
From: Tadeus Prastowo @ 2018-02-06 18:37 UTC (permalink / raw)
To: Peter Breuer, Peter Breuer; +Cc: Liu Hao, gcc-help, Jonathan Wakely
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
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: signed/unsigned integer conversion for right shift seems
2018-02-06 18:37 ` Tadeus Prastowo
@ 2018-02-06 18:47 ` Jonathan Wakely
2018-02-06 19:43 ` Peter T. Breuer
0 siblings, 1 reply; 40+ messages in thread
From: Jonathan Wakely @ 2018-02-06 18:47 UTC (permalink / raw)
To: Tadeus Prastowo; +Cc: Peter Breuer, Peter Breuer, Liu Hao, gcc-help
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.
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: signed/unsigned integer conversion for right shift seems
2018-02-06 18:47 ` Jonathan Wakely
@ 2018-02-06 19:43 ` Peter T. Breuer
2018-02-06 20:08 ` Tadeus Prastowo
0 siblings, 1 reply; 40+ messages in thread
From: Peter T. Breuer @ 2018-02-06 19:43 UTC (permalink / raw)
To: Jonathan Wakely
Cc: Tadeus Prastowo, Peter Breuer, Peter Breuer, Liu Hao, gcc-help
"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
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: signed/unsigned integer conversion for right shift seems
2018-02-06 19:43 ` Peter T. Breuer
@ 2018-02-06 20:08 ` Tadeus Prastowo
2018-02-06 20:15 ` Jonathan Wakely
0 siblings, 1 reply; 40+ messages in thread
From: Tadeus Prastowo @ 2018-02-06 20:08 UTC (permalink / raw)
To: Peter Breuer, Peter Breuer; +Cc: Jonathan Wakely, Liu Hao, gcc-help
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
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: signed/unsigned integer conversion for right shift seems
2018-02-06 20:08 ` Tadeus Prastowo
@ 2018-02-06 20:15 ` Jonathan Wakely
2018-02-07 9:59 ` Peter T. Breuer
0 siblings, 1 reply; 40+ messages in thread
From: Jonathan Wakely @ 2018-02-06 20:15 UTC (permalink / raw)
To: Tadeus Prastowo; +Cc: Peter Breuer, Peter Breuer, Liu Hao, gcc-help
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.
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: signed/unsigned integer conversion for right shift seems
2018-02-06 20:15 ` Jonathan Wakely
@ 2018-02-07 9:59 ` Peter T. Breuer
2018-02-07 12:28 ` David Brown
0 siblings, 1 reply; 40+ messages in thread
From: Peter T. Breuer @ 2018-02-07 9:59 UTC (permalink / raw)
To: Jonathan Wakely
Cc: Tadeus Prastowo, Peter Breuer, Peter Breuer, Liu Hao, gcc-help
"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
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: signed/unsigned integer conversion for right shift seems
2018-02-07 9:59 ` Peter T. Breuer
@ 2018-02-07 12:28 ` David Brown
[not found] ` <201802071634.w17GYiEL000904@nbd.it.uc3m.es>
0 siblings, 1 reply; 40+ messages in thread
From: David Brown @ 2018-02-07 12:28 UTC (permalink / raw)
To: ptb, Jonathan Wakely; +Cc: Tadeus Prastowo, Peter Breuer, Liu Hao, gcc-help
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.
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: signed/unsigned integer conversion for right shift seems
2018-02-06 18:27 ` Jonathan Wakely
2018-02-06 18:37 ` Tadeus Prastowo
@ 2018-02-06 19:28 ` Peter T. Breuer
2018-02-06 20:11 ` Jonathan Wakely
1 sibling, 1 reply; 40+ messages in thread
From: Peter T. Breuer @ 2018-02-06 19:28 UTC (permalink / raw)
To: Jonathan Wakely; +Cc: Peter Breuer, Liu Hao, Peter Breuer, gcc-help
"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
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: signed/unsigned integer conversion for right shift seems
2018-02-06 19:28 ` Peter T. Breuer
@ 2018-02-06 20:11 ` Jonathan Wakely
2018-02-06 23:49 ` Peter T. Breuer
0 siblings, 1 reply; 40+ messages in thread
From: Jonathan Wakely @ 2018-02-06 20:11 UTC (permalink / raw)
To: Peter Breuer; +Cc: Liu Hao, Peter Breuer, gcc-help
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.
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: signed/unsigned integer conversion for right shift seems
2018-02-06 20:11 ` Jonathan Wakely
@ 2018-02-06 23:49 ` Peter T. Breuer
2018-02-07 2:04 ` Vincent Lefevre
0 siblings, 1 reply; 40+ messages in thread
From: Peter T. Breuer @ 2018-02-06 23:49 UTC (permalink / raw)
To: Jonathan Wakely; +Cc: Peter Breuer, Liu Hao, Peter Breuer, gcc-help
"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
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: signed/unsigned integer conversion for right shift seems
2018-02-06 23:49 ` Peter T. Breuer
@ 2018-02-07 2:04 ` Vincent Lefevre
2018-02-07 9:30 ` Peter T. Breuer
0 siblings, 1 reply; 40+ messages in thread
From: Vincent Lefevre @ 2018-02-07 2:04 UTC (permalink / raw)
To: Peter T. Breuer; +Cc: Jonathan Wakely, Liu Hao, Peter Breuer, gcc-help
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)
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: signed/unsigned integer conversion for right shift seems
2018-02-07 2:04 ` Vincent Lefevre
@ 2018-02-07 9:30 ` Peter T. Breuer
0 siblings, 0 replies; 40+ messages in thread
From: Peter T. Breuer @ 2018-02-07 9:30 UTC (permalink / raw)
To: Vincent Lefevre
Cc: Peter T. Breuer, Jonathan Wakely, Liu Hao, Peter Breuer, gcc-help
"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
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: signed/unsigned integer conversion for right shift seems
2018-02-06 18:23 ` Peter T. Breuer
2018-02-06 18:27 ` Jonathan Wakely
@ 2018-02-06 21:18 ` Chris Hall
1 sibling, 0 replies; 40+ messages in thread
From: Chris Hall @ 2018-02-06 21:18 UTC (permalink / raw)
To: gcc-help
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
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: signed/unsigned integer conversion for right shift seems
2018-02-06 17:19 ` Peter T. Breuer
2018-02-06 17:35 ` Jonathan Wakely
@ 2018-02-06 17:44 ` Tadeus Prastowo
2018-02-06 19:00 ` Peter T. Breuer
1 sibling, 1 reply; 40+ messages in thread
From: Tadeus Prastowo @ 2018-02-06 17:44 UTC (permalink / raw)
To: ptb; +Cc: Jonathan Wakely, Liu Hao, Peter.T.Breuer, gcc-help
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
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: signed/unsigned integer conversion for right shift seems
2018-02-06 17:44 ` Tadeus Prastowo
@ 2018-02-06 19:00 ` Peter T. Breuer
0 siblings, 0 replies; 40+ messages in thread
From: Peter T. Breuer @ 2018-02-06 19:00 UTC (permalink / raw)
To: Tadeus Prastowo; +Cc: ptb, Jonathan Wakely, Liu Hao, Peter.T.Breuer, gcc-help
"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
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: signed/unsigned integer conversion for right shift seems against C99 rule
2018-02-06 15:03 signed/unsigned integer conversion for right shift seems against C99 rule Peter Breuer
2018-02-06 15:21 ` Tadeus Prastowo
2018-02-06 15:22 ` signed/unsigned integer conversion for right shift seems against C99 rule Liu Hao
@ 2018-02-06 15:22 ` Alexander Monakov
2 siblings, 0 replies; 40+ messages in thread
From: Alexander Monakov @ 2018-02-06 15:22 UTC (permalink / raw)
To: Peter Breuer; +Cc: gcc-help
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
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: signed/unsigned integer conversion for right shift seems against
@ 2018-02-06 16:38 Tadeus Prastowo
0 siblings, 0 replies; 40+ messages in thread
From: Tadeus Prastowo @ 2018-02-06 16:38 UTC (permalink / raw)
To: ptb; +Cc: Peter.T.Breuer, gcc-help
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
^ permalink raw reply [flat|nested] 40+ messages in thread
end of thread, other threads:[~2018-02-07 18:50 UTC | newest]
Thread overview: 40+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-02-06 15:03 signed/unsigned integer conversion for right shift seems against C99 rule Peter Breuer
2018-02-06 15:21 ` Tadeus Prastowo
2018-02-06 15:29 ` signed/unsigned integer conversion for right shift seems against Peter T. Breuer
2018-02-06 15:38 ` Tadeus Prastowo
2018-02-06 16:17 ` Peter T. Breuer
2018-02-06 15:22 ` signed/unsigned integer conversion for right shift seems against C99 rule Liu Hao
2018-02-06 15:31 ` David Brown
2018-02-06 15:50 ` signed/unsigned integer conversion for right shift seems Peter T. Breuer
2018-02-06 15:57 ` Jonathan Wakely
2018-02-06 16:42 ` Peter T. Breuer
2018-02-06 16:45 ` Jonathan Wakely
2018-02-06 17:19 ` Peter T. Breuer
2018-02-06 17:35 ` Jonathan Wakely
2018-02-06 18:23 ` Peter T. Breuer
2018-02-06 18:27 ` Jonathan Wakely
2018-02-06 18:37 ` Tadeus Prastowo
2018-02-06 18:47 ` Jonathan Wakely
2018-02-06 19:43 ` Peter T. Breuer
2018-02-06 20:08 ` Tadeus Prastowo
2018-02-06 20:15 ` Jonathan Wakely
2018-02-07 9:59 ` Peter T. Breuer
2018-02-07 12:28 ` David Brown
[not found] ` <201802071634.w17GYiEL000904@nbd.it.uc3m.es>
2018-02-07 16:39 ` Jonathan Wakely
2018-02-07 17:25 ` Peter T. Breuer
2018-02-07 17:39 ` Jonathan Wakely
2018-02-07 18:32 ` Peter T. Breuer
2018-02-07 18:41 ` Jonathan Wakely
2018-02-07 17:39 ` Tadeus Prastowo
2018-02-07 18:50 ` Peter T. Breuer
2018-02-07 18:11 ` Jonathan Wakely
2018-02-06 19:28 ` Peter T. Breuer
2018-02-06 20:11 ` Jonathan Wakely
2018-02-06 23:49 ` Peter T. Breuer
2018-02-07 2:04 ` Vincent Lefevre
2018-02-07 9:30 ` Peter T. Breuer
2018-02-06 21:18 ` Chris Hall
2018-02-06 17:44 ` Tadeus Prastowo
2018-02-06 19:00 ` Peter T. Breuer
2018-02-06 15:22 ` signed/unsigned integer conversion for right shift seems against C99 rule Alexander Monakov
2018-02-06 16:38 signed/unsigned integer conversion for right shift seems against Tadeus Prastowo
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).