Path: csiph.com!weretis.net!feeder8.news.weretis.net!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: Keith Thompson <Keith.S.Thompson+u@gmail.com>
Newsgroups: comp.std.c
Subject: Re: Why is shifting too far undefined behvaior?
Date: Tue, 21 Sep 2021 11:01:38 -0700
Organization: None to speak of
Lines: 75
Message-ID: <87tuidolj1.fsf@nosuchdomain.example.com>
References: <siceh0$1lm$1@solani.org>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: reader02.eternal-september.org; posting-host="bb72713767aed0d2b74b94bfa2480dba"; logging-data="15816"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/BI4Jw8nfzB6MgyA4BJ1rI"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)
Cancel-Lock: sha1:NMkfJNX5k7WqPS8guaS1/XEn7Ow= sha1:xMi+wBFNCtPfeYnPs1OBzIn2b7E=
Xref: csiph.com comp.std.c:6305

Philipp Klaus Krause <pkk@spth.de> writes:
> Looking at the C23 draft N2596, section J.2 (but this AFAIK has been the
> same forever), we see that there is undefined behavior, when "An
> expression is shifted by a negative number or by an amount greater than
> or equal to the width of the promoted expression (6.5.7)." or "An
> expression having signed promoted type is left-shifted and either the
> value of the expression is negative or the result of shifting would not
> be representable in the promoted type (6.5.7)."
>
> Does anyone know why this was made undefined (as opposed to yielding an
> unspecified value)? The C99 rationale doesn't mention anything.
>
> The only idea that comes to my mind is that it would be to allow
> implementations to trap at runtime when shifting too far, which might
> help with debugging.

Dennis Ritchie wrote about this in comp.arch in 2002, but didn't
specifically explain why it's undefined behavior rather than an
unspecified value.

https://yarchive.net/comp/c_shifts.html
    
    From: Dennis Ritchie <dmr@bell-labs.com>
    Newsgroups: comp.arch
    Subject: Re: shift instructions on different processors
    Date: Tue, 12 Feb 2002 04:47:05 +0000
    Message-ID: <3C689E49.65EB9FEB@bell-labs.com>
    
    glen herrmannsfeldt wrote:
    >
    > There have been questions on both C and Java newsgroups about
    > the effect of shift operations when the shift value equals or
    > exceeds the number of bits available to be shifted.
    >
    > I know that the reason for such a restriction is that many architectures
    > use only some bits of the shift amount.
    >
    > x86 uses the low 5 bits for 32 bit shifts, and low 6 bits for 64 bits.
    >
    > IBM S/360, S/370, S/390 etc., use the low 6 bits for 32 and 64 bits.
     ...
    
    Meissner followed up with various other architectures as well.
    
    I looked at my Interdata 8/32 manual (1975), which describes
    a 32-bit machine, and was amused to find, under the
    "Shift Left Logical" instruction,
    
      "... the shift count is specified by the least significant
      five bits of the second operand."
    
    I added a contemporaneous hand-written notation "!!" to this.
    
    On the next page, under "Shift Right Logical," it similarly
    says, "the least significant five bits of the second operand."
    
    Here my notation is an underlining, accompanied by "Shit!!"
    
    And that, children, is why the C and Java rules are as they are.
    The C manual in 6th Edition Unix didn't have the value restriction.
    K&R I did.
    
    	Dennis

Perhaps it was thought that shifting too far is analagous to integer
overflow, which has undefined behavior for signed types.  And Ritchie
may not have wanted to assume that no CPUs trap on a large shift.

K&R1 says "The result is undefined", not that it has undefined behavior
(I don't think K&R1 had the concept of undefined behavior).

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */