Path: csiph.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Bo Persson Newsgroups: comp.lang.c++ Subject: Re: Is this really necessary Date: Mon, 7 Jun 2021 21:58:44 +0200 Lines: 55 Message-ID: References: <20210606103347.06e3663e23b85fa28ff9cd39@cvine--nospam--.freeserve.co.uk> <87mts2vavc.fsf@nosuchdomain.example.com> <86y2bmce64.fsf@linuxsc.com> <87y2blqyhj.fsf@nosuchdomain.example.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net 2/7Kf4X+WaM0xiz0yQ/sSAoH4KGjIYjDsPPG/ATfydx1iFw0Bm Cancel-Lock: sha1:oIoC7tgKcW428sQx/IPHyzi5qo0= User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 In-Reply-To: <87y2blqyhj.fsf@nosuchdomain.example.com> Content-Language: sv Xref: csiph.com comp.lang.c++:80222 On 2021-06-07 at 21:13, Keith Thompson wrote: > Tim Rentsch writes: >> Keith Thompson writes: >>> Richard Damon writes: >>>> I haven't poured over the standard recently, but my memory was that >>>> the type family char / signed char / unsigned char all had this >>>> property, but if you actually accessed the values, signed char (and >>>> char is signed) had the possibility of a trap value (-0). >>> >>> I think you meant "(and char *if* signed)". >>> >>> As of C++17, signed types including signed char can use two's >>> complement, ones' complement, or signed magnitude, but: >>> For unsigned narrow character types, each possible bit pattern of >>> the value representation represents a distinct number. These >>> requirements do not hold for other types. >>> which means that plain char and signed char have no trap representations >>> and no padding bits. >> >> The passage quoted is about _un_signed narrow character types. >> It doesn't apply to signed char or to plain char of the signed >> variety. >> >> An earlier sentence (in the C++17 standard) says this >> >> For narrow character types, all bits of the object >> representation participate in the value representation. >> >> which does rule out padding bits, but it still admits the >> possibility of there being a trap representation. > > True, but C++17 has this rather odd wording later in the same paragraph: > > For each value i of type unsigned char in the range 0 to 255 > inclusive, there exists a value j of type char such that the result > of an integral conversion (7.8) from i to char is j, and the result > of an integral conversion from j to unsigned char is i. > > I believe this implies that there must be 256 distinct values of type > signed char (and plain char if it's signed), disallowing treating -0 or > -128 as a trap representation. > > What's odd about it is that it uses the value 255, so it wouldn't apply > that same requirement if CHAR_BIT > 8. > Not so odd really. On the CHAR_BIT == 9 system that I once used (Univac, and for C not C++), the char size was *not* chosen to get additional character values, but because the hardware had part-word operations that let you extract any quarter of the 36-bit word. That made using four 9-bit characters per word a lot more efficient than four-and-a-half 8-bit characters.