Re: Constants and undefined behavior

Path	csiph.com!eternal-september.org!feeder.eternal-september.org!nntp.eternal-september.org!.POSTED!not-for-mail
From	Tim Rentsch <tr.17687@z991.linuxsc.com>
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> (permalink)
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

Show key headers only | View raw

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> David Brown <david.brown@hesbynett.no> 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.

Back to comp.lang.c | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-12 12:27 -0700
  Re: Constants and undefined behavior David Brown <david.brown@hesbynett.no> - 2026-06-13 12:36 +0200
  Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-13 12:03 +0000
  Re: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-14 12:35 -0700

csiph-web