Path: csiph.com!news.mixmin.net!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c Subject: Re: Are there any conformant C compilers? Date: Mon, 12 Sep 2022 05:13:01 -0700 Organization: A noiseless patient Spider Lines: 53 Message-ID: <86illspz8y.fsf@linuxsc.com> References: <86zgfss6k3.fsf@linuxsc.com> <86r113rtuo.fsf@linuxsc.com> <87zgfqk9l4.fsf@nosuchdomain.example.com> <413ae987-3216-415f-88cf-8a6a0f7cfe4an@googlegroups.com> <68fbf792-a971-4e42-af84-c02257625abdn@googlegroups.com> <87ilmcyuv3.fsf@bsb.me.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader01.eternal-september.org; posting-host="117318903d4b6f4d84a8201305c52178"; logging-data="2379812"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/tlxmYbmxhO5AwfNx1acf/4huBcMJAws4=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:Es/Hyy98ptow99DAlp7CKd8ciA4= sha1:/H76MEh9o8nHUteXLlJ8nKaftWI= Xref: csiph.com comp.lang.c:167636 Ben Bacarisse writes: > Thiago Adams writes: > >> An interesting exercise is to think about true and false as >> constexpr. Imagine we have bool in the language but we don't >> have true and false constants. >> >> Then we declare: >> >> constexpr bool true = 1; >> constexpr bool false = 0; > > In this hypothetical situation, presumably 1 and 0 are the actual > values that bool objects represent. If not, this would be a > constraint violation as the standard is deliberately strict about > constexpr initialisers: they undergo no conversions. > > It's not 100% clear to me if, in the finished C23, > > constexpr bool my_bool = 1; > > will be permitted. I think not. I agree with (what I think is) your conclusion that the latest C23 draft standard (n3047) deems the initializing expression of my_bool a constraint violation. However, I do not think that n3047 disallows all conversions (that are implicit; AFAICS casting is always allowed). My understanding is that implicit conversions are allowed provided they do not cause a change of abstract value. For example, a definition such as constexpr unsigned int unsigned_one = 1; would be allowed, because the conversion from int to unsigned int does not change the abstract value 1. But the definition of my_bool above is not allowed, because the implicit conversion from int to bool changes the abstract value 1 to the abstract value true. Similarly a definition such as constexpr unsigned int all_ones = -1; would not be allowed, because the conversion from int to unsigned int changes the abstract value of -1 to a different abstract value (certainly an unsigned value cannot be less than zero, as -1 is). Disallowing the example definitions of my_bool and all_ones given above shows the foolishness of this rule. It's disappointing to see these further indications that the ISO C committee is drinking the C++ kool-aid.