Path: csiph.com!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c Subject: Re: does a double cast to unsigned makes sense in any circumstance? Date: Fri, 21 Jan 2022 17:19:52 -0800 Organization: A noiseless patient Spider Lines: 40 Message-ID: <86ee50pnwn.fsf@linuxsc.com> References: <86czl8kaew.fsf@levado.to> <86bl0ctree.fsf@levado.to> <86bl05rc7i.fsf@linuxsc.com> <3a6d2747-1a63-4ded-a568-3c05ca757827n@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader02.eternal-september.org; posting-host="434625eb2bdf5b21805d62a567edd212"; logging-data="31933"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+LrHwso5vAvHg8B0UfgrqHyWl3ke6lHT4=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:LX/uv42PGyuoyyIDoWD5mumg4sM= sha1:pZuUQ74h/Hi6iDOF8HCkE6ZO3Ro= Xref: csiph.com comp.lang.c:164530 "james...@alumni.caltech.edu" writes: > On Thursday, January 20, 2022 at 10:37:33 PM UTC-5, Tim Rentsch wrote: > >> James Kuyper writes: > > ... > >>> Note that while members of the basic character set are >>> required to be represented by non-negative values (6.2.5p3), >>> members of the extended character set are not. If char is >>> signed, they can be as low as CHAR_MIN, in which case >>> subtracting '0' necessarily results in undefined behavior. >>> [...] > > As Keith pointed out (and I had already conceded four days > before your message) that was a mistake on my part - the > relevant clause says "Otherwise, the new type is signed and the > value cannot be represented in it; either the result is > implementation-defined or an implementation-defined signal is > raised." (6.3.1.3p3). I noticed that, and saw Keith's response, and so chose not to post a followup myself. But I wasn't saying anything about converting back to a char, just about the subtraction. >> No, it doesn't. Subtracting one character value from another can >> give undefined behavior, but it doesn't have to, and indeed >> usually cannot. The only circumstance where it can is when char >> is signed and CHAR_MAX == INT_MAX. > > You're right - I was thinking about the possibility that > CHAR_MAX == INT_MAX, but I forgot to specify that this was a > pre-condition for my claim that the undefined behavior (which > should instead have been a referrence to 6.3.1.3p3) was > necessarily the result. Thank you for pointing this out. I was confident you would understand the point once I mentioned it. The followup was meant mainly for other readers who may have been confused.