Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: "undefined behavior"? Date: Tue, 18 Jun 2024 17:42:48 -0700 Organization: None to speak of Lines: 23 Message-ID: <87y171yd87.fsf@nosuchdomain.example.com> References: <666a095a$0$952$882e4bbb@reader.netnews.com> <877cet7qkl.fsf@nosuchdomain.example.com> <86frt9ixw2.fsf@linuxsc.com> MIME-Version: 1.0 Content-Type: text/plain Injection-Date: Wed, 19 Jun 2024 02:42:48 +0200 (CEST) Injection-Info: dont-email.me; posting-host="14c46e9d4441e9b6d7e573ea203ad727"; logging-data="1690205"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19ybK1iu2y3Rrx1TuelUp5x" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) Cancel-Lock: sha1:g6ei0Df0V/sC5xD82+RJC0CB/vg= sha1:7JOUh5dzkcLL9Z2E9SJBWVncjlc= Bytes: 2012 Tim Rentsch writes: > Keith Thompson writes: >> (I'd like to a future standard require plain char to be unsigned, >> but I don't know how likely that is.) > > It seems unnecessary given that the upcoming C standard > is choosing to mandate two's complement for all signed > integer types. It's less necessary, but I'd still like to see it. These days, strings very commonly hold UTF-8 data. The fact that bytes whose values exceed 127 are negative is conceptually awkward, even if everything happens to work. It rarely if ever makes sense to treat a character value as negative. (And of course signed char still exists, or int8_t if you prefer 8 bits vs. CHAR_BIT bits.) A drawback is that it could break existing (non-portable) code that assumes plain char is signed. -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com void Void(void) { Void(); } /* The recursive call of the void */