* 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; 39+ 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] 39+ 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; 39+ 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] 39+ 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; 39+ 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] 39+ 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; 39+ 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] 39+ 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; 39+ 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] 39+ 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; 39+ 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] 39+ 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; 39+ 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] 39+ 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; 39+ 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] 39+ 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; 39+ 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] 39+ 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; 39+ 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] 39+ 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; 39+ 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] 39+ 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; 39+ 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] 39+ 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; 39+ 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] 39+ 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; 39+ 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] 39+ 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; 39+ 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] 39+ 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; 39+ 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] 39+ 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; 39+ 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] 39+ 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; 39+ 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] 39+ 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; 39+ 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] 39+ 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; 39+ 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] 39+ 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; 39+ 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] 39+ 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; 39+ 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] 39+ messages in thread
[parent not found: <201802071634.w17GYiEL000904@nbd.it.uc3m.es>]
* Re: signed/unsigned integer conversion for right shift seems [not found] ` <201802071634.w17GYiEL000904@nbd.it.uc3m.es> @ 2018-02-07 16:39 ` Jonathan Wakely 2018-02-07 17:25 ` Peter T. Breuer 0 siblings, 1 reply; 39+ messages in thread From: Jonathan Wakely @ 2018-02-07 16:39 UTC (permalink / raw) To: Peter Breuer; +Cc: David Brown, lh_mouse, gcc-help On 7 February 2018 at 16:34, Peter T. Breuer wrote: > Dear David et al > > > I'll repeat the paragraph from my summary this morning. Please don't, your sophistry is still off-topic. Repeating it doesn't make it any less so. The insight you finally gave me credit for wasn't even mine originally, but as I'd also said in an earlier mail, you aren't paying attention. Too busy stroking yourself for being so clever. Now please go away, you tedious fart. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: signed/unsigned integer conversion for right shift seems 2018-02-07 16:39 ` Jonathan Wakely @ 2018-02-07 17:25 ` Peter T. Breuer 2018-02-07 17:39 ` Tadeus Prastowo ` (2 more replies) 0 siblings, 3 replies; 39+ messages in thread From: Peter T. Breuer @ 2018-02-07 17:25 UTC (permalink / raw) To: Jonathan Wakely; +Cc: Peter Breuer, David Brown, lh_mouse, gcc-help "Also sprach Jonathan Wakely:" > > On 7 February 2018 at 16:34, Peter T. Breuer wrote: > > I'll repeat the paragraph from my summary this morning. > > Please don't, your sophistry is still off-topic. Repeating it doesn't Kindly explain why explaining is off-topic in your opinion. > make it any less so. Sophistry \Soph"ist*ry\, n. [OE. sophistrie, OF. sophisterie.] The art or process of reasoning; logic. [Obs.] [1913 Webster] Correct. I am exact, which is the minimum anyone can be. > The insight you finally gave me credit for wasn't even mine It is. Kindly point to somebody who says it before you? For example, I see from you Tue 16.45: You've already been told that 6.5.7 says "The integer promotions are performed on each of the operands. " and says nothing about conversions. which is not it. Either you still don't get what IT is, or ... I don't know. To give you the clue, here is my response (my caps) at 20.11: I see nothing that says that conversions should NOT be applied to their operators. Got it yet? Here is where you did give the clue. I'll help again with caps: > What, specifically, do you see in 6.5.7 that allows the > conversion specified by the general rule of conversions > > If one operand has an unsigned type T whose conversion rank is > at least as high as that of the other operand's type, then the other > operand is converted to type T. > > NOT to be applied? > > BECAUSE it doesn't say they are applied. As I pointed out in Get it? You finally exposed your REASONING, for the very first and only time. That single instance of displayed reasoning was enough for me. You could have saved yourself you had merely gone to that ordinary length beforehand, but no. > originally, but as I'd also said in an earlier mail, you aren't paying > attention. Too busy stroking yourself for being so clever. I am not clever! Just ordinary! > Now please go away, you tedious fart. Pot. PTB ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: signed/unsigned integer conversion for right shift seems 2018-02-07 17:25 ` Peter T. Breuer @ 2018-02-07 17:39 ` Tadeus Prastowo 2018-02-07 18:50 ` Peter T. Breuer 2018-02-07 17:39 ` Jonathan Wakely 2018-02-07 18:11 ` Jonathan Wakely 2 siblings, 1 reply; 39+ messages in thread From: Tadeus Prastowo @ 2018-02-07 17:39 UTC (permalink / raw) To: Peter Breuer; +Cc: Jonathan Wakely, David Brown, lh_mouse, gcc-help On Wed, Feb 7, 2018 at 6:25 PM, Peter T. Breuer <ptb@inv.it.uc3m.es> wrote: > "Also sprach Jonathan Wakely:" >> >> On 7 February 2018 at 16:34, Peter T. Breuer wrote: >> > I'll repeat the paragraph from my summary this morning. >> >> Please don't, your sophistry is still off-topic. Repeating it doesn't > > Kindly explain why explaining is off-topic in your opinion. > >> make it any less so. > > Sophistry \Soph"ist*ry\, n. [OE. sophistrie, OF. sophisterie.] > The art or process of reasoning; logic. [Obs.] [1913 Webster] > > Correct. I am exact, which is the minimum anyone can be. Good. Now since you claimed that you were a mathematical logician in one of the previous e-mails, I will let you know as a newcomer in this mailing list that the set of axioms in this mailing list that you keep posting to includes the proposition that said that "a discussion on the C language issue is disallowed", another proposition that said that "if a discussion is about a C language issue, then the discussion is off-topic", and another proposition that said that "an off-topic discussion shall not be discussed any longer." So, can't you stop now, please, you who claimed to be http://dblp.uni-trier.de/pers/hd/b/Breuer:Peter_T= ? -- Best regards, Tadeus ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: signed/unsigned integer conversion for right shift seems 2018-02-07 17:39 ` Tadeus Prastowo @ 2018-02-07 18:50 ` Peter T. Breuer 0 siblings, 0 replies; 39+ messages in thread From: Peter T. Breuer @ 2018-02-07 18:50 UTC (permalink / raw) To: Tadeus Prastowo Cc: Peter Breuer, Jonathan Wakely, David Brown, lh_mouse, gcc-help "Also sprach Tadeus Prastowo:" > Good. Now since you claimed that you were a mathematical logician in > one of the previous e-mails, I will let you know as a newcomer in this > mailing list that the set of axioms in this mailing list that you keep > posting to includes the proposition that said that "a discussion on > the C language issue is disallowed", another proposition that said I am not discussing the C language, let alone any "issue" you may or may not have with it. You see no opinion on C from me at all. I have not expressed whether or not I think the gcc computed goto is a good idea, for example (I don't like it but have never used it, and it surely has its place - it's semantically horrible, however, and gcc statements as expressions is also bad). It was quite a specific question: is gcc right in this instance. If you thought it was off topic for gcc-help, I would have been glad to ask elsewhere, at your suggestion. For the rest, I merely reply to what is emailed to me. My best guess from the weird replies is indeed that I've overtaxed the natives, unwittingly, and I apologise for that. I recall now, belatedly, that the "help" newsgroups for an area are generally for dispensing somewhat platitudinous advice to newbies. That explains a lot. > that "if a discussion is about a C language issue, then the discussion > is off-topic", and another proposition that said that "an off-topic What "C language issue" do you claim this is about? We want to know if gcc is right, since on the face of it it seemed to contradict the standard's pithy words on conversions. The correct response was "no it doesn't because 6.5 says that conversions are not applied for >> and 6.3.18 does not list >> among what things conversion is applied to and 6.1 says that nothing else than 6.5 defaulting to 6.3.18 is allowed". Fin. Instead, a hail of rubbish ensued, to which I conscienciously replied, nicely pointing out what was wrong with it, because I am a nice and kind person, and when somebody writes nonsense, I am nice and kind enough to correct them, less they continue to do so and hurt themselves. I should have been clever enough to realise I was talking to the janitor. > discussion shall not be discussed any longer." Nobody is discussing anything. The correct statement is as above: "signed >> unsigned" in gcc should not convert to "unsigned >> unsigned" even though that IS an "automatic" conversion in the standard because $6.5 says that conversions are not applied for >> and $6.3.18 does not list >> among things conversion is applied to and $6.1 says that nothing else than $6.5 defaulting to $6.3.18 SHALL BE allowed QED. It should not have been hard for you. > So, can't you stop now, please, you who claimed to be > http://dblp.uni-trier.de/pers/hd/b/Breuer:Peter_T= ? I did not claim it, and I insist you spell correctly, if at all. PTB ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: signed/unsigned integer conversion for right shift seems 2018-02-07 17:25 ` Peter T. Breuer 2018-02-07 17:39 ` Tadeus Prastowo @ 2018-02-07 17:39 ` Jonathan Wakely 2018-02-07 18:32 ` Peter T. Breuer 2018-02-07 18:11 ` Jonathan Wakely 2 siblings, 1 reply; 39+ messages in thread From: Jonathan Wakely @ 2018-02-07 17:39 UTC (permalink / raw) To: Peter Breuer; +Cc: David Brown, lh_mouse, gcc-help On 7 February 2018 at 17:25, Peter T. Breuer <ptb@inv.it.uc3m.es> wrote: > "Also sprach Jonathan Wakely:" >> >> On 7 February 2018 at 16:34, Peter T. Breuer wrote: >> > I'll repeat the paragraph from my summary this morning. >> >> Please don't, your sophistry is still off-topic. Repeating it doesn't > > Kindly explain why explaining is off-topic in your opinion. > >> make it any less so. > > Sophistry \Soph"ist*ry\, n. [OE. sophistrie, OF. sophisterie.] > The art or process of reasoning; logic. [Obs.] [1913 Webster] > > Correct. I am exact, which is the minimum anyone can be. I prefer this from https://www.merriam-webster.com/dictionary/sophistry Thus sophist (which comes from Greek sophist?s, meaning "wise man" or "expert") earned a negative connotation as "a captious or fallacious reasoner." Sophistry is reasoning that seems plausible on a superficial level but is actually unsound, or reasoning that is used to deceive. > >> The insight you finally gave me credit for wasn't even mine > > It is. Kindly point to somebody who says it before you? https://gcc.gnu.org/ml/gcc-help/2018-02/msg00019.html https://gcc.gnu.org/ml/gcc-help/2018-02/msg00020.html You may claim it wasn't precise enough for you, but that's your problem for being an idiot. Nobody here is under any obligation to provide you with a formal education in the C standard. You were given the answers, and several clues how to interpret the standard if you cared to. You chose to ignore or misinterpret them, because they didn't suit you. Call that exactness if you wish, I call it arrogance and pissiness. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: signed/unsigned integer conversion for right shift seems 2018-02-07 17:39 ` Jonathan Wakely @ 2018-02-07 18:32 ` Peter T. Breuer 2018-02-07 18:41 ` Jonathan Wakely 0 siblings, 1 reply; 39+ messages in thread From: Peter T. Breuer @ 2018-02-07 18:32 UTC (permalink / raw) To: Jonathan Wakely; +Cc: Peter Breuer, David Brown, lh_mouse, gcc-help "Also sprach Jonathan Wakely:" > > Correct. I am exact, which is the minimum anyone can be. > > I prefer this from https://www.merriam-webster.com/dictionary/sophistry > Thus sophist (which comes from Greek sophist?s, meaning "wise man" or > "expert") earned a negative connotation as "a captious or fallacious It is ambiguous in the sense that both it and its opposite are possible dictionary meanings, a rare distinction. Your choice was number 2 in the usual dictionary list. I preferred number 1 both on the basis of accuracy in this instance and popularity as per the dictionary ordering. I could care less ;) It illustrated that you should be more careful, so I allowed it. > reasoner." Sophistry is reasoning that seems plausible on a > superficial level but is actually unsound, or reasoning that is used > to deceive. Unfortunately for your likely intention, my reasoning is both deep and correct and it is on display preciely in order that you may be able to take issue with it at any point in it. Please go ahead. Otherwise I'll take that as childish meaningless nonsense and be happy. > >> The insight you finally gave me credit for wasn't even mine > > It is. Kindly point to somebody who says it before you? > https://gcc.gnu.org/ml/gcc-help/2018-02/msg00019.html (1) That doesn't work as a method of answering. You are supposed to quote the precise passage you mean and (2) explicitly state the reasoning that forms your opinion of it Otherwise you are being ambiguous. I'll quote 19 in its entirety, noting beforehand that it does not say it. My (1): See the definition of "usual arithmetic conversions" in the text of the standard and note that they are not applied to bitwise shift arguments (they undergo integer promotions individually). Where in there do you see it said? I don't. Let me remind you that the single keyword was BECAUSE. Here's my (2): He does not reveal any reasoning, so that is empty of content because we require reasoning to connect the dots between the standard and the conclusion (no conversions). To explain further the standard contains many statements, none of them is that conversions shall not be applied in this case, so one requires reasoning to connect things in the standard with the conclusion one wants. He does not provide it. You did, with that ONE WORD ("because"), for the first time. Do you see a "because" or a "therefore" or a "since" or an "as" or a "whence" etc. in msg 19? That single word "because" was enough of a clue for me to construct the whole probable chain of reasoning that you couldn't be arsed to express. How do you think people can follow your reasoning if you do not enunciate it? That "because" was enough on its own to start me looking through the whole standard word by word first for the DATA (such as that paraphrased in msg 19) that might permit the logic chain to be constructed on top of it, and secondly for the RULES OF DEDUCTION that would form the body of the logic chain. Do you get it now? 6.1 provides the rule (8.3.18 =/> ~p /\ 6.5 =/> ~p) => p That form of reasoning would be invalid without its authority. Invalid reasoning is invalid reasoning, full stop. Don't explain your rule of deduction and what authorizes it and you are reasoning invalidly. If you cannot read that, or for some other reason you find your mind just "skips over it" witout taking it in, please LET ME KNOW and I will rephrase in less formal language. It is not unusual for people to be "symbol-blind". I'm phrasing it in a form that I natively expect you to be familiar and comfortable with, but if I am wrong with that guess, you'll have to tell me. It's no skin one way or another. > https://gcc.gnu.org/ml/gcc-help/2018-02/msg00020.html I'm not going to bother because your credibility is already zero with these things, having shown so many times (e.g. 19 above) that you fail to get it. Oh logicks, count thy number that I have written, proved complete, and sound. > You may claim it wasn't precise enough for you, but that's your I have no idea or opinion on preciseness. It is simply irrelevant, > problem for being an idiot. Nobody here is under any obligation to Reading anything I write should tell you and anyone what is really up. I can't make you see what you appear not to be able to see although the huge majority of people in the world can ... All I can comfort you with is that it is a recognized generic problem of engineers. And administrators. Also poor lawyers. Actually, poor anything. Yea! It's common! Unfortunately, no cure is available, but it begins with the realization that there may be something there that you are missing. Treat it like one of those aliens you can only see if you don't look straight at them ;). > provide you with a formal education in the C standard. You were given Nobody is doing so and nobody is obliged to do anything, except that it is a simple and universal courtesy from and to human beings to explain their reasoning. To put it another less charitable way, people who can't see or explain their reasoning are subhuman nazis, and so one aims to show one is not by always showing ones reasoning. That will leave it vunerable to challenge and the idea is precisely that. > the answers, and several clues how to interpret the standard if you You still don't get it, but we know that. It is YOU that I am interpreting, not the standard. YOU need to show YOUR reasoning. Only that enables its worth to be judged, and that is the common courtesy that one human being leaves another. > cared to. You chose to ignore or misinterpret them, because they I have done nothing of the kind. It seems to me that when I have asked you to show "What, specifically, do you see in 6.5.7 that allows the conversion specified by the general rule of conversions ... NOT to be applied?" that YOU are misinterpreting that as a request to be pointed at WHERE in the standard is the BASIS for a deduction that conversion may not be applied (in fact must not, as it turns out). I did not ask that. I asked for WHAT IS THE LOGICAL RULE. Nothing else can be of interest. I was expecting you to point at what in the end turned out to be 6.3 first paragraph final sentence, where it announces the DEDUCTION RULE that says it's either in 6.3.18 or in 6.5 or it is not allowed. I put it down to your blindness to the fact that your own and the standard's logic exists and are things. In the standard's case, the rules of the logic have to be written down somewhere, because that is what standards do. You kept on not referring me to it and claiming that you had. Indeed, you gave no reasoning at all for your statements, thus saying absolutely nothing. It is a problem of "level". > didn't suit you. Call that exactness if you wish, I call it arrogance > and pissiness. I call it normal, ordinary, everyday stuff, that every human being needs and does in order to do their own stuff in a coherent fashion. To be human, you show you have the self-knowledge to be able to explain your own mental workings. It's only machines (well, and animals) that can't. I hope that the penny is if not dropped, on it way into the slot. Remember that ONE WORD ("because") was enough for me, and please reflect. Regards PTB ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: signed/unsigned integer conversion for right shift seems 2018-02-07 18:32 ` Peter T. Breuer @ 2018-02-07 18:41 ` Jonathan Wakely 0 siblings, 0 replies; 39+ messages in thread From: Jonathan Wakely @ 2018-02-07 18:41 UTC (permalink / raw) To: Peter Breuer; +Cc: David Brown, lh_mouse, gcc-help On 7 February 2018 at 18:32, Peter T. Breuer wrote: > "Also sprach Jonathan Wakely:" >> > Correct. I am exact, which is the minimum anyone can be. >> >> I prefer this from https://www.merriam-webster.com/dictionary/sophistry >> Thus sophist (which comes from Greek sophist?s, meaning "wise man" or >> "expert") earned a negative connotation as "a captious or fallacious > > It is ambiguous in the sense that both it and its opposite are possible > dictionary meanings, a rare distinction. Your choice was number 2 in > the usual dictionary list. I preferred number 1 both on the basis of > accuracy in this instance and popularity as per the dictionary ordering. > > I could care less ;) > > It illustrated that you should be more careful, so I allowed it. > >> reasoner." Sophistry is reasoning that seems plausible on a >> superficial level but is actually unsound, or reasoning that is used >> to deceive. > > Unfortunately for your likely intention, my reasoning is both deep and > correct and it is on display preciely in order that you may be able to > take issue with it at any point in it. You are https://www.reddit.com/r/iamverysmart/ and I claim my five pounds. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: signed/unsigned integer conversion for right shift seems 2018-02-07 17:25 ` Peter T. Breuer 2018-02-07 17:39 ` Tadeus Prastowo 2018-02-07 17:39 ` Jonathan Wakely @ 2018-02-07 18:11 ` Jonathan Wakely 2 siblings, 0 replies; 39+ messages in thread From: Jonathan Wakely @ 2018-02-07 18:11 UTC (permalink / raw) To: Peter Breuer; +Cc: David Brown, lh_mouse, gcc-help On 7 February 2018 at 17:25, Peter T. Breuer <ptb@inv.it.uc3m.es> wrote: > "Also sprach Jonathan Wakely:" >> >> On 7 February 2018 at 16:34, Peter T. Breuer wrote: >> > I'll repeat the paragraph from my summary this morning. >> >> Please don't, your sophistry is still off-topic. Repeating it doesn't > > Kindly explain why explaining is off-topic in your opinion. > >> make it any less so. > > Sophistry \Soph"ist*ry\, n. [OE. sophistrie, OF. sophisterie.] > The art or process of reasoning; logic. [Obs.] [1913 Webster] > > Correct. I am exact, which is the minimum anyone can be. > >> The insight you finally gave me credit for wasn't even mine > > It is. Kindly point to somebody who says it before you? For example, I > see from you Tue 16.45: That was the first time I said it, in: https://gcc.gnu.org/ml/gcc-help/2018-02/msg00029.html Then again in: https://gcc.gnu.org/ml/gcc-help/2018-02/msg00031.html Then again in: https://gcc.gnu.org/ml/gcc-help/2018-02/msg00034.html Then again, referring you to an earlier post, in: https://gcc.gnu.org/ml/gcc-help/2018-02/msg00041.html Only then did you finally get your head out of your arse, saying "An interesting new theory, if late to the party." It was neither new nor late, you just refused to see what was being said. Maybe if you spent less time expecting formal logic in response to drivel you'd be able to communicate like a functioning human. Now please, piss off. ^ permalink raw reply [flat|nested] 39+ 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; 39+ 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] 39+ 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; 39+ 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] 39+ 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; 39+ 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] 39+ 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; 39+ 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] 39+ 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; 39+ 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] 39+ 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; 39+ 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] 39+ 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; 39+ 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] 39+ 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; 39+ 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] 39+ 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; 39+ 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] 39+ messages in thread
end of thread, other threads:[~2018-02-07 18:50 UTC | newest] Thread overview: 39+ 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 ` Tadeus Prastowo 2018-02-07 18:50 ` 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 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
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).