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: Constants and undefined behavior Date: Fri, 14 Aug 2026 12:35:57 -0700 Organization: A noiseless patient Spider Lines: 37 Message-ID: <86ecg07aw2.fsf@linuxsc.com> References: <10v7b32$2u85v$1@dont-email.me> <86tsrc8d0b.fsf@linuxsc.com> <1108pb9$omm$1@reader1.panix.com> <110a34q$b2kq$2@kst.eternal-september.org> <110bsqd$9ab$1@reader1.panix.com> <110cm0v$116qm$2@kst.eternal-september.org> <110dm6p$17r3s$1@dont-email.me> <110ekic$1naub$6@dont-email.me> <110ghmv$21vi3$1@dont-email.me> <110hmi7$2e85g$1@kst.eternal-september.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Date: Fri, 14 Aug 2026 19:36:02 +0000 (UTC) Injection-Info: dont-email.me; logging-data="2956047"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19goicxdE+H9XR8hHBb4kloGfZ0EbPBmU4="; posting-host="34d543ba31754db8d869ebd4dc5daf69" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:9fYfGVnAkWwfkNJ2HL3X4uYGetg= sha1:Nx9zafO8476VQEFtcxe21xx3P2A= sha256:Un8diso5OWFaZIz15IHOmZavp8ZJX8LYtoWotyDCfz4= sha1:3LJtGjXyrc3OMraTwgC46JZzyRA= sha256:ldIa5WvvUlQxLr+ZENraNZilhTOhT5qalysvkd7GM3U= Xref: csiph.com comp.lang.c:401169 Keith Thompson writes: > David Brown writes: [...] >> I think the semantics of this "loops can be assumed to terminate" >> are clearly defined in the standard. [...] > > I disagree that the semantics are clearly defined. N3220 6.8.6.1p4 > is specified in terms of what an implementation may "assume", not in > terms of the semantics of the program. It isn't obvious that the semantics of "may be assumed to terminate" is even well defined by the text of the C standard; it certainly is not clearly defined. > One can conclude that this > means that the program has undefined behavior if the assumption is > violated, but that's not directly stated. I don't know how many C > programmers know the standard well enough to reach that conclusion. > I'm not even 100% sure it's accurate. > > The permission was added in C11 with little fanfare. It's not > mentioned in the list of major changes in the C11 Foreword. > The cases where it applies may be rarer than I had assumed, but > it at least has the potential to break existing code that was well > defined in C99. > > The rationale is to provide more opportunities for optimization, > but it's not at all clear (at least to me) that it's particularly > successful. If cases where it can cause problems are rare, then > presumably cases where it's actually useful are rare. (That may > be an oversimplification.) If someone is counting votes my vote is to remove this rule from the C standard. If there were a compiler option to act as though this rule were not in force I would always use that option. It's worse than useless.