Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: Keith Thompson <kst-u@mib.org>
Newsgroups: comp.lang.c
Subject: Re: C wish list
Date: Wed, 20 Mar 2019 15:15:02 -0700
Organization: None to speak of
Lines: 66
Message-ID: <lnr2b1gpll.fsf@kst-u.example.com>
References: <de7f6c95-d2a8-4f26-9416-f72305578c3b@googlegroups.com> <yDpYuPXgbPvO0TB2QttltgH9QFlBQ@bongo-ra.co> <11b51bdf-7847-40fc-bdf5-b3777f41b4da@googlegroups.com> <lnva0dgsyz.fsf@kst-u.example.com> <q6ucrp$sc1$2@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Info: reader02.eternal-september.org; posting-host="a26d008c97410be935366452bc5d340d"; logging-data="27216"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19i59Iw4fajB3zyZ2bJHlPg"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)
Cancel-Lock: sha1:iBL3d88IV4Ai+/oU0Um3/RqhGoA= sha1:XFrRGuinrjYbiSzru+t4F6YzXVQ=
Xref: csiph.com comp.lang.c:142144

David Brown <david.brown@hesbynett.no> writes:
> On 20/03/2019 22:02, Keith Thompson wrote:
>> Howard Chu <highlandsun@gmail.com> writes:
>> [...]
>>> Currently,
>>>
>>>     int32_t i = 1 << 31;
>>>
>>> is undefined. Even using uint32_t. But it has a clear meaning: set the
>>> high bit of this word. Any CPU in use today would have no trouble
>>> performing the expressed operation, the resulting bit pattern is
>>> unambiguous. If the language spec declared that all integers are two's
>>> complement there would be no reason for this to be undefined.
>> 
>> A quibble: The expression `1 << 31` would still have undefined behavior
>> (or at least would overflow) if int is 16 bits.  But let's assume you
>> meant:
>>      int32_t i = INT32_C(1) << 31;
>> or
>>      int32_t i = 1L << 31;
>> 
>> If the language were changed to require two's-complement, that
>> would not directly imply anything about the behavior of `1L << 31`.
>> Making that well defined would have to be an explicit and distinct
>> change.  The C++ proposal does include that change, but it seems to
>> be controversial.  (I haven't read the entire proposal, and I don't
>> understand the "SF F N A SA" abbreviations used in the poll results.)
>> 
>
> "Strongly for", "for", "neutral", "against", "strongly against".

Thanks.

The relevant poll in the C++ proposal is:

    Left shift should be the same for signed and unsigned (overrides
    previous poll).

which presumably means that 1<<31 would be well defined for 32-bit
two's-complement int (it would yield -2**31).  The voting was:

    Strongly for:     6
    For:              5
    Neutral:          5
    Against:          0
    Strongly against: 1

So it's not as controversial as I thought it was.

The proposed wording is:

    The value of E1 << E2 is E1 left-shifted E2 bit positions; vacated
    bits are zero-filled. The value of the result is E1×2^E2, reduced
    modulo 2^N, where N is the number of value bits in the result type.

(^, of course denotes a superscript/exponentiation.)

One advantage of requiring two's-complement is that it makes some things
possible to describe more briefly in the standard.

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0907r1.html

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */