From: Jonathan Wakely <jwakely.gcc@gmail.com>
To: Peter Breuer <ptb@inv.it.uc3m.es>
Cc: Liu Hao <lh_mouse@126.com>,
Peter Breuer <Peter.T.Breuer@gmail.com>,
gcc-help <gcc-help@gcc.gnu.org>
Subject: Re: signed/unsigned integer conversion for right shift seems
Date: Tue, 06 Feb 2018 20:11:00 -0000 [thread overview]
Message-ID: <CAH6eHdT=CDpQu_AamowNo4_=MyFs-FS_0xyyJpn-6gEHn5-o3Q@mail.gmail.com> (raw)
In-Reply-To: <201802061927.w16JRrNZ027236@nbd.it.uc3m.es>
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.
next prev parent reply other threads:[~2018-02-06 20:11 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
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 Alexander Monakov
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: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 [this message]
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAH6eHdT=CDpQu_AamowNo4_=MyFs-FS_0xyyJpn-6gEHn5-o3Q@mail.gmail.com' \
--to=jwakely.gcc@gmail.com \
--cc=Peter.T.Breuer@gmail.com \
--cc=gcc-help@gcc.gnu.org \
--cc=lh_mouse@126.com \
--cc=ptb@inv.it.uc3m.es \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).