This is the mail archive of the
mailing list for the GDB project.
Re: [PATCH 0/2] Fix invalid left shift of negative value.
- From: Kevin Buettner <kevinb at redhat dot com>
- To: "Ulrich Weigand" <uweigand at de dot ibm dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Wed, 11 Nov 2015 12:27:08 -0700
- Subject: Re: [PATCH 0/2] Fix invalid left shift of negative value.
- Authentication-results: sourceware.org; auth=none
- References: <20151110154243 dot 43d38f49 at pinnacle dot lan> <20151111172327 dot 383F51407 at oc7340732750 dot ibm dot com>
On Wed, 11 Nov 2015 18:23:27 +0100 (CET)
"Ulrich Weigand" <firstname.lastname@example.org> 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.