Path: csiph.com!eternal-september.org!feeder.eternal-september.org!nntp.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c Subject: Re: this girl calls c ugly Date: Fri, 05 Jun 2026 06:41:23 -0700 Organization: A noiseless patient Spider Lines: 77 Message-ID: <86bjdpayv0.fsf@linuxsc.com> References: <10v7b32$2u85v$1@dont-email.me> <10vcqjc$con8$1@dont-email.me> <10vcui4$buur$3@kst.eternal-september.org> <10vd1tu$ekvl$1@dont-email.me> <10vel6r$l1g$1@reader1.panix.com> <10vemqf$r5qe$1@dont-email.me> <10vfsmo$16jap$1@kst.eternal-september.org> <10vgqhf$1d6tp$1@dont-email.me> <10vh074$1epj1$2@dont-email.me> <10vh1eo$1ei50$2@dont-email.me> <10vh5f0$1g1ke$1@dont-email.me> <10vhgau$1iv7l$1@dont-email.me> <10vhkgl$1k67h$1@dont-email.me> <10vie7n$1r8io$1@kst.eternal-september.org> <10vm8tj$3uus7$7@dont-email.me> <10vmimv$2tjoi$3@kst.eternal-september.org> <86ecipcbqa.fsf@linuxsc.com> <10vnlgu$382un$2@kst.eternal-september.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Date: Fri, 05 Jun 2026 13:41:26 +0000 (UTC) Injection-Info: dont-email.me; logging-data="1251505"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+K4qGiBSddn2nnidfApOs27Od4XyRFCcA="; posting-host="ab312f3c60546a52db3a021dc13141bd" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:Sy6cB01VXG6WXH0EMRakCgPkgNw= sha1:SQJp1bEfQN2PqXoSCmw+PUZSMyk= sha256:+VwnT5G+SCt2itdZX+Clrdf+vUfGSovdK12bMwoQEAU= sha1:HpsT8yMGi6978aSPgZyhPnUecI0= Xref: csiph.com comp.lang.c:399748 Keith Thompson writes: > Tim Rentsch writes: > >> Keith Thompson writes: >> >>> Note that in a context that requires a constant expression, overflow is >>> a constraint violation. For example, a case label like: >>> >>> case (INT_MAX + 1) * 0: >>> >>> must be diagnosed at compile time. >> >> gcc disagrees with you. > > What makes you think so? > > [...] I'm skipping this and proceeding on to the original question. > But taking a closer look at the standard, I'm not 100% sure that the > language requires a diagnostic, though I think that's the intent. > The relevant constraint is: > > Each constant expression shall evaluate to a constant that is > in the range of representable values for its type. > > If I squint really hard, I can argue that the entire expression > has to be a constant expression, but it doesn't say that its > subexpressions are constant expressions -- and *if* INT_MAX + > 1 evaluates to INT_MIN in the current implementation, then > (INT_MAX + 1) * 0 evaluates to 0 and therefore satisfies the > constraint. My reasoning is as follows. To determine if the constraint is satisfied, the compiler must first evaluate the expression (INT_MAX + 1) * 0. To evaluate the expression (INT_MAX + 1) * 0, the compiler must first evaluate the sub-expression (INT_MAX + 1). Because the expression (INT_MAX + 1) overflows, the behavior is undefined, and the compiler is free to decide that the value of the sub-expression (INT_MAX + 1) is, let's say, 12. The compiler next evaluates the overall expression as 12*0, which is 0 (an int). This result of the overall expression satisfies the constraint, and so the compiler is not obliged to generate a diagnostic. Going back, when evaluating (INT_MAX + 1), the compiler could have decided to choose the value 3.14159e47. In that case the value of the overall expression would be 0.0. This value has type double, which does not satisfy the constraint that the result have integer type. Thus if the compiler had made this decision then a diagnostic would be required. Overall conclusion: whether a diagnostic is required depends on what behavior is chosen for the construct (INT_MAX + 1). The implementation could choose a behavior where the constraint is satisfied, or it could choose a behavior where the constraint is not satisfied. > But INT_MAX + 1 could legally trap, for example, and I don't > believe it was intended that a given expression can be a constant > expression or not depending on the vagaries of the behavior of an > instance of UB. I see no basis for this belief. My conclusions are based on what the C standard actually says, rather than guesses about some unstated "intentions". I think you would do well to reach your conclusions based more on the actual text of the C standard, and less on your interpretation of what the text was "intended" to mean.