public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Kevin Buettner <kevinb@redhat.com>
To: "Ulrich Weigand" <uweigand@de.ibm.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH 0/2] Fix invalid left shift of negative value.
Date: Wed, 11 Nov 2015 19:27:00 -0000	[thread overview]
Message-ID: <20151111122708.69c496d3@pinnacle.lan> (raw)
In-Reply-To: <20151111172327.383F51407@oc7340732750.ibm.com>

On Wed, 11 Nov 2015 18:23:27 +0100 (CET)
"Ulrich Weigand" <uweigand@de.ibm.com> wrote:

> Kevin Buettner wrote:
> 
> > Looking at one of your changes from part 1/2...
> > 
> > -    (LONGEST) -1 << (TYPE_LENGTH (base_type) * TARGET_CHAR_BIT - 1);
> > +    -((LONGEST) 1 << (TYPE_LENGTH (base_type) * TARGET_CHAR_BIT - 1));
> > 
> > What aspect of the original expression is not defined by the C standard?
> 
> The C standard (either C99 or C11) says:
> 
>   The result of E1 << E2 is E1 left-shifted E2 bit positions; vacated bits
>   are filled with zeros. If E1 has an unsigned type, the value of the result
>   is E1 * 2^E2, reduced modulo one more than the maximum value representable
>   in the result type. If E1 has a signed type and nonnegative value, and
>   E1 * 2^E2 is representable in the result type, then that is the resulting
>   value; otherwise, the behavior is undefined.
> 
> Note the "otherwise" case includes any E1 of signed type and negative value.
> 
> (For >>, the behavior in the latter case is at least implementation-
> defined, and not undefined.)

Thank you for providing the relevant text from the standard.

Do you (or anyone else) know the rationale for specifying that the
behavior of << is undefined for (signed) negative values?

My guess is that it's due to the fact that there are several ways
to represent signed numbers and that the standard has to account for
all of them.

If that guess is correct, then it seems to me that using the unary
minus operator to help construct a mask is most likely broken for some
signed number representations.  (I.e. we won't get the mask that
we've come to expect from the two's complement representation.)  If so,
we should consider whether we want to find a more portable way to
construct these masks.

Regardless, I want to have a better understanding of this matter
before approving Dominik's patch.

Kevin

  reply	other threads:[~2015-11-11 19:27 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-10 11:16 Dominik Vogt
2015-11-10 11:17 ` [PATCH 1/2] " Dominik Vogt
2015-11-10 11:18 ` [PATCH 2/2] " Dominik Vogt
2015-11-10 22:42 ` [PATCH 0/2] " Kevin Buettner
2015-11-11 17:23   ` Ulrich Weigand
2015-11-11 19:27     ` Kevin Buettner [this message]
2015-11-17  5:09       ` Kevin Buettner
2015-11-17 14:13         ` Pedro Alves
2015-11-17 17:33           ` Paul_Koning
2015-11-17 15:10 ` [PATCH 3/2] " Dominik Vogt
2015-11-17 17:49   ` Kevin Buettner
2015-11-30  8:54   ` Dominik Vogt
2015-12-06 14:17     ` [SIM patch] " Joel Brobecker
2015-12-15 13:15       ` Andreas Arnez

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=20151111122708.69c496d3@pinnacle.lan \
    --to=kevinb@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=uweigand@de.ibm.com \
    /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).