Path: csiph.com!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c++ Subject: Re: Is this really necessary Date: Mon, 07 Jun 2021 12:13:44 -0700 Organization: None to speak of Lines: 52 Message-ID: <87y2blqyhj.fsf@nosuchdomain.example.com> References: <20210606103347.06e3663e23b85fa28ff9cd39@cvine--nospam--.freeserve.co.uk> <87mts2vavc.fsf@nosuchdomain.example.com> <86y2bmce64.fsf@linuxsc.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: reader02.eternal-september.org; posting-host="da0ef0006e1a2be3c584df7adb5e6866"; logging-data="6893"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/iSHLJR445G0LwesHFRuRa" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) Cancel-Lock: sha1:buiCgpY5day9EP0YBr9IFOfUlbE= sha1:rOhj0xPH/lreFWmxcmAAKATSrGc= Xref: csiph.com comp.lang.c++:80221 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). -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com Working, but not speaking, for Philips Healthcare void Void(void) { Void(); } /* The recursive call of the void */