Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #12699

Re: left shift count >= width of type

Show all headers | View raw

[Multipart message — attachments visible in raw view] - view raw

On 11/2/2011 12:34 PM, James Kuyper wrote:
[...]
> 
> The relevant clause is phrased in terms of whether not the the result
> can be represented in the type, not the width of the type, For the
> expression E1 << E2, "If E1 has a signed type and nonnegative value, and
> E1 x 2^E2 is representable in the result type, then that is the
> resulting value; otherwise, the behavior is undefined" (6.5.7p5)
> 
> Therefore, for a 32-bit int, even 1 << 31 is problematic. That's an
> example of why it's better to use unsigned types for most bit-masking
> purposes.

thanks for pointing that out. I indeed agree that bit masking may result
in unexpected behavior if signed are used instead of unsigned, that's
why I'm usually used to have my own data types not to get confused.

> 
> However - and this is the key point - this is not a constraint, it's
> undefined behavior. Conforming implementations are NOT required to issue
> a diagnostic.
> 

And I believe that is what happened in this case. Has to be said that
this code is nearly 10 year old and back then probably gcc was not as
rigorous as is today.

>> Since this snippet is part of a very old implementation of g21k compiler
>> for ADSP21xxx, I'm wondering why do we need to shift at all, isn't the
>> above foo assignment equal to the following:
>>
>> foo = bar;
> 
> Since this code has undefined behavior if INT_MAX < pow(2,32), I would
> hope that it was intended for an implementation where INT_MAX >
> pow(2,32). I  have no idea whether the "g2lk compiler for ADSP21xxx" is
> such an implementation. If it were, then the foo assignment statement
> would not be equivalent to "foo = bar".

Got your point. Indeed, compiling on my machine where INT_MAX <
pow(2,32) the behavior is undefined, while it may very well be that in
the author's case the INT_MAX > pow(2,32).
That is also why there is a definition used in the code:

> #if HOST_BITS_PER_LONG > HOST_BITS_PER_INT
> #define HOST_BITS_PER_WIDE_INT HOST_BITS_PER_LONG
> #define HOST_WIDE_INT long
> #else
> #define HOST_BITS_PER_WIDE_INT HOST_BITS_PER_INT
> #define HOST_WIDE_INT int
> #endif

where there's a clear intention to distinguish between the two cases.
Essential point is that apparently no attention was paid to the fact
that int might be signed.

> 
> However, it seem more plausible that the author of this code didn't know
> or care about the fact that it had undefined behavior; it did what he
> wanted it to do on the particular implementation where it needed to
> work, and no attention was paid to whether or not it would do so
> anywhere else.

Considering that this compiler is specific for a family of DSPs, I
rather think that was the case back then.

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

left shift count >= width of type Alessandro Basili <alessandro.basili@cern.ch> - 2011-11-02 10:55 +0100
  Re: left shift count >= width of type James Kuyper <jameskuyper@verizon.net> - 2011-11-02 07:34 -0400
    Re: left shift count >= width of type Keith Thompson <kst-u@mib.org> - 2011-11-02 13:47 -0700
    Re: left shift count >= width of type Alessandro Basili <alessandro.basili@cern.ch> - 2011-11-04 17:46 +0100
      Re: left shift count >= width of type James Kuyper <jameskuyper@verizon.net> - 2011-11-04 13:12 -0400
        Re: left shift count >= width of type Alessandro Basili <alessandro.basili@cern.ch> - 2011-11-05 19:17 +0100
  Re: left shift count >= width of type Thad Smith <ThadSmith@acm.org> - 2011-11-02 20:22 -0600

csiph-web