Path: csiph.com!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c++ Subject: Re: Is this really necessary Date: Sat, 07 Aug 2021 10:25:52 -0700 Organization: A noiseless patient Spider Lines: 56 Message-ID: <86tuk12mlb.fsf@linuxsc.com> 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=us-ascii Injection-Info: reader02.eternal-september.org; posting-host="0a1d8104bbc0e7f8706fc1dabce7c8e9"; logging-data="22220"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+pCufySJPe/KXYHjR0P1VplCsMmvD12Y4=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:F5yqiGHUVOh8GF0tR74+GkaNV4s= sha1:/YvuP1Tpr0hKQN6qdqa0byoUO84= Xref: csiph.com comp.lang.c++:80787 Keith Thompson writes: > 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. > > C++20 (at least in the draft I have) requires 2**CHAR_BIT distinct > values for the narrow character types (char, unsigned char, signed char, > and char8_t). Ahhh, as usual for the C++ standard. Yes repeat no. Thank you for the additional information.