Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #399456 > unrolled thread
| Started by | fir <profesor.fir@gmail.com> |
|---|---|
| First post | 2026-05-27 19:53 +0200 |
| Last post | 2026-05-30 11:18 +0200 |
| Articles | 20 on this page of 360 — 21 participants |
Back to article view | Back to comp.lang.c
this girl calls c ugly fir <profesor.fir@gmail.com> - 2026-05-27 19:53 +0200
Re: this girl calls c ugly fir <profesor.fir@gmail.com> - 2026-05-27 20:15 +0200
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-27 18:49 -0500
Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-28 04:53 +0000
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-28 02:35 -0500
Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-28 23:32 +0000
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-28 20:07 -0500
Re: this girl calls c ugly Bonita Montero <Bonita.Montero@gmail.com> - 2026-05-28 11:48 +0200
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-28 09:18 +0200
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-28 04:57 -0500
Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-28 23:35 +0000
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 09:52 +0200
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-29 05:20 -0500
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-29 13:22 +0200
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-29 15:16 -0500
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-30 13:52 +0200
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-30 14:40 +0200
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-30 16:36 +0200
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-30 15:48 -0500
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-31 11:14 +0200
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-31 13:25 -0500
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-31 22:14 +0200
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 15:22 +0200
Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-30 03:49 +0000
Re: this girl calls c ugly "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-05-28 12:47 -0700
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 09:56 +0200
Re: this girl calls c ugly "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-05-29 11:00 -0700
Re: this girl calls c ugly fir <profesor.fir@gmail.com> - 2026-05-28 17:12 +0200
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-28 14:07 -0500
Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-28 23:54 +0000
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 10:02 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 12:19 +0100
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 14:46 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 14:22 +0100
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 17:15 +0200
Re: this girl calls c ugly scott@slp53.sl.home (Scott Lurndal) - 2026-05-29 15:59 +0000
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 17:12 +0100
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 18:48 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 19:09 +0100
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 22:00 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 22:14 +0100
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-29 12:09 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 17:05 +0100
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 18:34 +0200
Re: this girl calls c ugly tTh <tth@none.invalid> - 2026-05-29 19:29 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 18:53 +0100
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-29 12:28 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 20:49 +0100
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 22:03 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-29 13:56 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 22:54 +0100
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-29 15:52 -0700
Re: this girl calls c ugly James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-05-29 20:31 -0400
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-30 02:03 +0100
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-29 19:02 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-30 12:12 +0100
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-30 12:29 +0000
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-30 13:56 +0100
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-30 16:43 -0700
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-31 03:37 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-30 19:53 -0700
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-02 12:16 +0200
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-31 11:47 +0200
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-02 12:55 +0200
Re: this girl calls c ugly Richard Harnden <richard.nospam@gmail.invalid> - 2026-05-31 09:12 +0100
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-31 11:49 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-31 11:10 +0100
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-31 13:18 +0200
Re: this girl calls c ugly James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-05-31 10:24 -0400
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-31 17:35 +0200
Re: this girl calls c ugly James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-05-31 12:46 -0400
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-31 22:24 +0200
Re: this girl calls c ugly James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-05-31 18:26 -0400
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-01 08:28 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-31 15:54 -0700
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-01 08:39 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-01 02:33 -0700
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-02 11:48 +0200
Re: this girl calls c ugly James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-06-02 06:37 -0400
Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-02 05:06 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-02 16:28 +0000
Re: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-04 03:37 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-04 16:31 +0000
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-04 13:36 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-04 23:49 +0000
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-04 18:04 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-06 03:10 +0000
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-05 23:50 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-08 02:20 +0000
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-08 12:39 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-08 23:15 +0000
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-08 18:51 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-09 09:46 +0000
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-09 15:07 -0700
Re: Constants and undefined behavior antispam@fricas.org (Waldek Hebisch) - 2026-06-09 01:25 +0000
Re: Constants and undefined behavior James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-06-09 18:29 -0400
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-09 16:01 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-10 12:36 +0000
Re: Constants and undefined behavior Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-11 16:49 +0200
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-11 15:20 +0000
Re: Constants and undefined behavior Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-11 18:08 +0200
Re: Constants and undefined behavior antispam@fricas.org (Waldek Hebisch) - 2026-06-11 16:30 +0000
Re: Constants and undefined behavior Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-11 20:52 +0200
Re: Constants and undefined behavior antispam@fricas.org (Waldek Hebisch) - 2026-06-12 02:20 +0000
Re: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-06 15:47 -0700
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-06 16:36 -0700
Re: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-06 16:43 -0700
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-06 17:41 -0700
Re: Constants and undefined behavior Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-05 10:41 +0200
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-05 10:49 -0700
Re: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-06 16:15 -0700
Re: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-06 18:06 -0700
Re: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-07 22:34 -0700
Re: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-08 23:05 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-09 10:19 +0000
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-09 15:12 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-10 14:37 +0000
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-10 18:30 +0000
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-10 14:55 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-10 23:32 +0000
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-10 14:47 -0700
Re: Constants and undefined behavior David Brown <david.brown@hesbynett.no> - 2026-06-11 08:56 +0200
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-11 11:38 +0000
Re: Constants and undefined behavior David Brown <david.brown@hesbynett.no> - 2026-06-11 14:05 +0200
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-11 15:38 -0700
Re: Constants and undefined behavior scott@slp53.sl.home (Scott Lurndal) - 2026-06-11 23:07 +0000
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-11 17:43 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-12 02:02 +0000
Re: Constants and undefined behavior Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-11 17:34 +0200
Re: Constants and undefined behavior David Brown <david.brown@hesbynett.no> - 2026-06-12 10:58 +0200
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-12 12:27 -0700
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-11 13:29 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-12 02:08 +0000
Re: Constants and undefined behavior David Brown <david.brown@hesbynett.no> - 2026-06-12 11:02 +0200
Re: Constants and undefined behavior Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-11 17:45 +0200
Re: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-10 15:11 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-10 22:44 +0000
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-10 16:19 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-11 11:50 +0000
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-11 16:28 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-11 23:46 +0000
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-11 18:29 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-12 01:54 +0000
Re: Constants and undefined behavior David Brown <david.brown@hesbynett.no> - 2026-06-12 11:37 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-02 05:35 -0700
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-02 06:29 -0700
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-02 16:10 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-02 15:29 -0700
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-05 06:41 -0700
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-05 11:24 -0700
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-08 08:35 -0700
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-08 17:33 +0000
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-09 00:54 -0700
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-09 10:08 +0000
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-08 13:40 -0700
Meaning of "expression" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-08 14:05 -0700
Expression statements (was Re: Meaning of "expression") Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-09 15:17 +0200
Re: Expression statements (was Re: Meaning of "expression") Bart <bc@freeuk.com> - 2026-06-09 14:53 +0100
Re: Expression statements (was Re: Meaning of "expression") Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-09 16:30 +0200
Re: Expression statements (was Re: Meaning of "expression") David Brown <david.brown@hesbynett.no> - 2026-06-09 17:13 +0200
Re: Expression statements (was Re: Meaning of "expression") Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-09 15:34 -0700
Re: Expression statements (was Re: Meaning of "expression") David Brown <david.brown@hesbynett.no> - 2026-06-10 09:04 +0200
Re: Expression statements (was Re: Meaning of "expression") Bart <bc@freeuk.com> - 2026-06-10 11:10 +0100
Re: Expression statements (was Re: Meaning of "expression") David Brown <david.brown@hesbynett.no> - 2026-06-10 13:29 +0200
Re: Expression statements (was Re: Meaning of "expression") Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-10 03:17 -0700
Re: Expression statements (was Re: Meaning of "expression") David Brown <david.brown@hesbynett.no> - 2026-06-10 13:43 +0200
Re: Expression statements (was Re: Meaning of "expression") Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-10 14:08 -0700
Re: Expression statements (was Re: Meaning of "expression") David Brown <david.brown@hesbynett.no> - 2026-06-11 09:10 +0200
Re: Expression statements (was Re: Meaning of "expression") Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-11 20:29 +0200
Re: Expression statements (was Re: Meaning of "expression") David Brown <david.brown@hesbynett.no> - 2026-06-12 12:55 +0200
Re: Expression statements (was Re: Meaning of "expression") Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-11 20:12 +0200
Re: Expression statements (was Re: Meaning of "expression") James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-06-11 15:13 -0400
Re: Expression statements (was Re: Meaning of "expression") Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-12 00:37 +0200
Re: Expression statements (was Re: Meaning of "expression") scott@slp53.sl.home (Scott Lurndal) - 2026-06-11 23:05 +0000
Re: Expression statements (was Re: Meaning of "expression") Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-12 01:18 +0200
Re: Expression statements (was Re: Meaning of "expression") Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-11 17:41 -0700
Re: Expression statements (was Re: Meaning of "expression") James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-06-11 20:41 -0400
Re: Expression statements (was Re: Meaning of "expression") tTh <tth@none.invalid> - 2026-06-09 19:27 +0200
Re: Expression statements (was Re: Meaning of "expression") Bart <bc@freeuk.com> - 2026-06-09 19:19 +0100
Re: Expression statements (was Re: Meaning of "expression") Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-09 15:22 -0700
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-06 03:22 +0000
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-05 23:56 -0700
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-07 13:37 +0000
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-07 15:09 -0700
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-08 02:33 +0000
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-08 00:16 -0700
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-08 12:41 +0000
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-08 17:37 +0000
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-09 16:05 +0200
Re: this girl calls c ugly "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-02 13:59 -0700
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-02 13:05 +0000
Parentheses (was: this girl calls c ugly) Bart <bc@freeuk.com> - 2026-06-02 14:38 +0100
Re: Parentheses (was: this girl calls c ugly) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-02 15:19 +0000
Re: Parentheses antispam@fricas.org (Waldek Hebisch) - 2026-06-03 22:30 +0000
Re: Parentheses Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-03 16:24 -0700
Re: Parentheses antispam@fricas.org (Waldek Hebisch) - 2026-06-04 02:03 +0000
Re: Parentheses Bart <bc@freeuk.com> - 2026-06-04 01:12 +0100
Re: Parentheses antispam@fricas.org (Waldek Hebisch) - 2026-06-04 01:58 +0000
Re: Parentheses Bart <bc@freeuk.com> - 2026-06-04 11:37 +0100
Re: Parentheses cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-04 10:51 +0000
Re: Parentheses Bart <bc@freeuk.com> - 2026-06-04 12:47 +0100
Re: Parentheses Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-04 14:57 +0200
Re: Parentheses cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-04 14:31 +0000
[OT] Fancy graphics (was Re: this girl calls c ugly) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-02 15:54 +0200
Re: [OT] Fancy graphics (was Re: this girl calls c ugly) Bart <bc@freeuk.com> - 2026-06-02 15:19 +0100
Re: [OT] Fancy graphics (was Re: this girl calls c ugly) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-02 15:19 +0000
Re: [OT] Fancy graphics (was Re: this girl calls c ugly) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-02 17:39 +0200
Re: [OT] Fancy graphics (was Re: this girl calls c ugly) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-02 16:36 +0000
Re: [OT] Fancy graphics (was Re: this girl calls c ugly) scott@slp53.sl.home (Scott Lurndal) - 2026-06-02 21:33 +0000
Re: [OT] Fancy graphics (was Re: this girl calls c ugly) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-02 14:43 -0700
Re: [OT] Fancy graphics (was Re: this girl calls c ugly) ram@zedat.fu-berlin.de (Stefan Ram) - 2026-06-02 17:08 +0000
Re: [OT] Fancy graphics (was Re: this girl calls c ugly) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-02 19:19 +0000
Re: [OT] Fancy graphics (was Re: this girl calls c ugly) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-04 00:11 +0000
Re: [OT] Fancy graphics (was Re: this girl calls c ugly) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-02 15:39 -0700
Re: [OT] Fancy graphics (was Re: this girl calls c ugly) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-03 13:14 +0000
Re: this girl calls c ugly scott@slp53.sl.home (Scott Lurndal) - 2026-06-02 15:10 +0000
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-02 15:31 +0000
Re: this girl calls c ugly James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-05-31 10:15 -0400
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-31 16:29 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-31 03:45 -0700
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-31 04:02 -0700
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-31 09:04 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-31 18:11 +0100
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-31 19:34 +0000
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-31 19:10 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-01 11:12 +0100
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-01 12:36 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-01 14:26 -0700
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-04 02:34 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-04 12:40 +0100
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-04 14:35 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-04 14:18 +0100
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-04 15:47 +0200
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-04 15:57 +0200
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-04 16:27 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-04 16:46 +0100
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-04 20:15 +0200
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-04 20:54 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-04 20:29 +0100
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-04 14:06 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-04 22:47 +0100
Famous (hopefully last) words [on this topic] Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-05 00:27 +0200
Re: Famous (hopefully last) words [on this topic] Bad Post <invalid@invalid.invalid> - 2026-06-05 01:20 +0100
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-04 16:09 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-05 00:44 +0100
Re: this girl calls c ugly "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-04 17:26 -0700
Re: this girl calls c ugly antispam@fricas.org (Waldek Hebisch) - 2026-06-05 12:58 +0000
Re: this girl calls c ugly "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-05 14:27 -0700
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-05 02:47 +0000
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-05 00:53 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-05 11:04 +0100
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-05 05:34 -0700
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-06 03:45 +0000
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-06 03:44 +0000
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-06 07:39 +0200
Re: this girl calls c ugly "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-04 15:25 -0700
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-05 09:29 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-05 12:39 +0100
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-05 15:42 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-05 16:50 +0100
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-05 11:09 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-05 20:29 +0100
Re: this girl calls c ugly scott@slp53.sl.home (Scott Lurndal) - 2026-06-04 16:18 +0000
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-04 17:23 +0100
Re: this girl calls c ugly scott@slp53.sl.home (Scott Lurndal) - 2026-06-04 16:47 +0000
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-04 19:57 +0100
Re: this girl calls c ugly scott@slp53.sl.home (Scott Lurndal) - 2026-06-04 20:34 +0000
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-04 22:28 +0100
Re: this girl calls c ugly scott@slp53.sl.home (Scott Lurndal) - 2026-06-04 21:58 +0000
Re: this girl calls c ugly Richard Harnden <richard.nospam@gmail.invalid> - 2026-06-04 23:25 +0100
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-05 02:49 +0000
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-04 19:47 +0200
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-04 21:04 +0200
Re: this girl calls c ugly Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-06-04 19:13 +0000
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-05 10:34 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-04 12:11 -0700
Re: this girl calls c ugly James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-06-04 16:33 -0400
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-04 14:16 -0700
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-05 00:02 +0000
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-04 18:36 -0700
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-05 02:54 +0000
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-05 05:49 -0700
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-05 11:01 -0700
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-05 11:53 -0700
Re: this girl calls c ugly Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-06-04 18:45 +0000
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-04 20:19 +0000
Re: this girl calls c ugly scott@slp53.sl.home (Scott Lurndal) - 2026-06-04 20:31 +0000
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-04 20:41 +0000
Re: this girl calls c ugly scott@slp53.sl.home (Scott Lurndal) - 2026-06-04 20:49 +0000
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-05 00:03 +0000
Re: this girl calls c ugly scott@slp53.sl.home (Scott Lurndal) - 2026-06-05 00:18 +0000
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-05 03:02 +0000
Re: this girl calls c ugly scott@slp53.sl.home (Scott Lurndal) - 2026-06-05 14:04 +0000
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-06 03:49 +0000
Re: this girl calls c ugly scott@slp53.sl.home (Scott Lurndal) - 2026-06-06 15:13 +0000
Re: this girl calls c ugly scott@slp53.sl.home (Scott Lurndal) - 2026-06-06 17:53 +0000
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-04 11:59 -0700
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-04 15:21 +0200
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-04 06:38 -0700
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-01 09:52 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-01 02:42 -0700
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-01 12:50 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-01 11:47 +0100
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-01 12:55 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-01 14:39 -0700
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-01 15:11 -0700
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-02 08:41 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-02 02:07 -0700
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-02 11:38 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-02 05:01 -0700
It is not futile to change the subject line (Was: this girl calls c ugly) gazelle@shell.xmission.com (Kenny McCormack) - 2026-06-02 12:39 +0000
Re: It is not futile to change the subject line (Was: this girl calls c ugly) gazelle@shell.xmission.com (Kenny McCormack) - 2026-06-02 12:42 +0000
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-02 11:46 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-02 11:09 +0100
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-02 05:25 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-02 14:20 +0100
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-02 15:12 -0700
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-02 04:16 -0700
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-01 15:23 -0700
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-01 16:06 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-01 23:24 +0100
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-02 11:35 +0200
Operator precedence in other (non-C, but "C-like") languages (Was: something about a girl) gazelle@shell.xmission.com (Kenny McCormack) - 2026-06-02 12:36 +0000
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-01 11:04 +0000
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-01 14:04 +0200
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-01 18:48 +0000
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-01 21:04 +0100
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-02 09:17 +0200
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-02 09:09 +0200
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-02 12:07 +0000
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-02 14:37 +0200
Microcontroller software stacks (was Re: this girl calls c ugly) scott@slp53.sl.home (Scott Lurndal) - 2026-06-02 15:06 +0000
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-04 03:58 -0700
Re: this girl calls c ugly dave_thompson_2@comcast.net - 2026-06-06 19:02 -0400
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-31 19:11 +0000
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-31 16:08 -0700
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-31 16:32 -0700
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-31 17:12 -0700
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-30 14:07 +0200
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 18:10 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 19:18 +0100
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 22:17 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 21:47 +0100
Re: this girl calls c ugly James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-05-29 15:57 -0400
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 22:34 +0200
Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-29 23:18 +0000
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-30 01:26 +0100
Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-30 04:25 +0000
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-30 12:01 +0100
Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-31 00:29 +0000
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-31 10:59 +0100
Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-01 00:33 +0000
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-01 02:26 +0100
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-31 13:24 +0200
Re: this girl calls c ugly Bonita Montero <Bonita.Montero@gmail.com> - 2026-05-29 08:09 +0200
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-29 04:15 -0500
Re: this girl calls c ugly Bonita Montero <Bonita.Montero@gmail.com> - 2026-05-29 14:58 +0200
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-30 01:04 -0500
Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-29 23:20 +0000
Re: this girl calls c ugly Bonita Montero <Bonita.Montero@gmail.com> - 2026-05-30 11:18 +0200
Page 8 of 18 — ← Prev page 1 … 6 7 [8] 9 10 … 18 Next page →
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-06-11 23:46 +0000 |
| Subject | Re: Constants and undefined behavior |
| Message-ID | <110fhc6$aem$1@reader1.panix.com> |
| In reply to | #399925 |
In article <110fgbi$1qf9f$1@kst.eternal-september.org>,
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>cross@spitfire.i.gajendra.net (Dan Cross) writes:
>> In article <110cre9$13aa9$1@kst.eternal-september.org>,
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>>cross@spitfire.i.gajendra.net (Dan Cross) writes:
>>>[...]
>>>> I see you did not read the other messages in the (sub)thread,
>>>> but ok, here it is again, in C:
>>>>
>>>> ```
>>>> term% cat what.c
>>>> #include <stdio.h>
>>>> int main(void) { for (unsigned int k = 0; k != 1; k += 2); return 0; }
>>>> void hello(void) { printf("Hello, World!\n"); }
>>>> term% clang --version | sed 1q
>>>> clang version 22.1.6
>>>> term% clang -Wall -pedantic -pedantic-errors -O1 -std=c23 -o what what.c
>>>> what.c:2:58: warning: for loop has empty body [-Wempty-body]
>>>> 2 | int main(void) { for (unsigned int k = 0; k != 1; k += 2); return 0; }
>>>> | ^
>>>> what.c:2:58: note: put the semicolon on a separate line to silence this warning
>>>> 1 warning generated.
>>>> term% ./what
>>>> Hello, World!
>>>> term%
>>>> ```
>>>
>>>I see the same behavior.
>>>
>>>The following largely repeats what I've written previously in
>>>this thread.
>>>
>>>Apparently the authors of clang decided that this statement in N3220
>>>6.8.6.p4:
>>>
>>> An iteration statement may be assumed by the implementation to
>>> terminate if its controlling expression is not a constant
>>> expression, ...
>>>
>>>means that a program that violates that assumption has undefined
>>>behavior. I intensely dislike both the rule and the way it's stated,
>>>but I agree that the conclusion that the behavior is undefined is
>>>a reasonable one.
>>
>> I think the behavior is technical "unspecified" in the sense of
>> the C standard, but yes, this is the important bit. The
>> controlling expresion is not constant, and the loop doesn't meet
>> any of the other criteria set forth in sec 6.8.6 para 4 for,
>> therefore, the translator may assume it terminates (it is
>> unspecified whether or not it does; either behavior is correct.
>> GCC, for example, appears not to make the same assumption).
>
>Why do you think the behavior is unspecified rather that undefined?
>
>Unspecified behavior is defined as: "behavior, that results from
>the use of an unspecified value, or other behavior upon which
>this document provides two or more possibilities and imposes
>no further requirements on which is chosen in any instance".
>(Implementation-defined behavior differs from unspecified behavior
>in that the implementation must document how the choice is made.)
>
>What are the "two more more possibilities" in this case?
The two choices are that the implementation may assume the loop
terminates, or it may not, but it doesn't say which. I don't
think that the language permits it to be UB. But I could be
wrong. It's a bit of a distinction without a difference as far
as the outcome is concerned.
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-06-11 18:29 -0700 |
| Subject | Re: Constants and undefined behavior |
| Message-ID | <110fnem$1s3nm$1@kst.eternal-september.org> |
| In reply to | #399926 |
cross@spitfire.i.gajendra.net (Dan Cross) writes:
> In article <110fgbi$1qf9f$1@kst.eternal-september.org>,
> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>cross@spitfire.i.gajendra.net (Dan Cross) writes:
>>> In article <110cre9$13aa9$1@kst.eternal-september.org>,
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>>>cross@spitfire.i.gajendra.net (Dan Cross) writes:
>>>>[...]
>>>>> I see you did not read the other messages in the (sub)thread,
>>>>> but ok, here it is again, in C:
>>>>>
>>>>> ```
>>>>> term% cat what.c
>>>>> #include <stdio.h>
>>>>> int main(void) { for (unsigned int k = 0; k != 1; k += 2); return 0; }
>>>>> void hello(void) { printf("Hello, World!\n"); }
>>>>> term% clang --version | sed 1q
>>>>> clang version 22.1.6
>>>>> term% clang -Wall -pedantic -pedantic-errors -O1 -std=c23 -o what what.c
>>>>> what.c:2:58: warning: for loop has empty body [-Wempty-body]
>>>>> 2 | int main(void) { for (unsigned int k = 0; k != 1; k += 2); return 0; }
>>>>> | ^
>>>>> what.c:2:58: note: put the semicolon on a separate line to silence this warning
>>>>> 1 warning generated.
>>>>> term% ./what
>>>>> Hello, World!
>>>>> term%
>>>>> ```
>>>>
>>>>I see the same behavior.
>>>>
>>>>The following largely repeats what I've written previously in
>>>>this thread.
>>>>
>>>>Apparently the authors of clang decided that this statement in N3220
>>>>6.8.6.p4:
>>>>
>>>> An iteration statement may be assumed by the implementation to
>>>> terminate if its controlling expression is not a constant
>>>> expression, ...
>>>>
>>>>means that a program that violates that assumption has undefined
>>>>behavior. I intensely dislike both the rule and the way it's stated,
>>>>but I agree that the conclusion that the behavior is undefined is
>>>>a reasonable one.
>>>
>>> I think the behavior is technical "unspecified" in the sense of
>>> the C standard, but yes, this is the important bit. The
>>> controlling expresion is not constant, and the loop doesn't meet
>>> any of the other criteria set forth in sec 6.8.6 para 4 for,
>>> therefore, the translator may assume it terminates (it is
>>> unspecified whether or not it does; either behavior is correct.
>>> GCC, for example, appears not to make the same assumption).
>>
>>Why do you think the behavior is unspecified rather that undefined?
>>
>>Unspecified behavior is defined as: "behavior, that results from
>>the use of an unspecified value, or other behavior upon which
>>this document provides two or more possibilities and imposes
>>no further requirements on which is chosen in any instance".
>>(Implementation-defined behavior differs from unspecified behavior
>>in that the implementation must document how the choice is made.)
>>
>>What are the "two more more possibilities" in this case?
>
> The two choices are that the implementation may assume the loop
> terminates, or it may not, but it doesn't say which. I don't
> think that the language permits it to be UB. But I could be
> wrong. It's a bit of a distinction without a difference as far
> as the outcome is concerned.
No, those are not the two choices. An assumption made by an
implementation is not behavior ("external appearance or action").
An implementation might invoke some behavior as a result of some
assumption.
If a loop doesn't terminate and the implementation assumes that
it does, the standard says nothing about the resulting behavior.
It doesn't provide two or more options for the actual behavior.
That's classic UB.
We've seen cases here where the actual behavior is falling through
into a function that's never called. That's certainly not a
possibility provided by the standard.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-06-12 01:54 +0000 |
| Subject | Re: Constants and undefined behavior |
| Message-ID | <110fos1$bfa$1@reader1.panix.com> |
| In reply to | #399933 |
In article <110fnem$1s3nm$1@kst.eternal-september.org>,
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>cross@spitfire.i.gajendra.net (Dan Cross) writes:
>> In article <110fgbi$1qf9f$1@kst.eternal-september.org>,
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>>cross@spitfire.i.gajendra.net (Dan Cross) writes:
>>>> In article <110cre9$13aa9$1@kst.eternal-september.org>,
>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>>>>cross@spitfire.i.gajendra.net (Dan Cross) writes:
>>>>>[...]
>>>>>> I see you did not read the other messages in the (sub)thread,
>>>>>> but ok, here it is again, in C:
>>>>>>
>>>>>> ```
>>>>>> term% cat what.c
>>>>>> #include <stdio.h>
>>>>>> int main(void) { for (unsigned int k = 0; k != 1; k += 2); return 0; }
>>>>>> void hello(void) { printf("Hello, World!\n"); }
>>>>>> term% clang --version | sed 1q
>>>>>> clang version 22.1.6
>>>>>> term% clang -Wall -pedantic -pedantic-errors -O1 -std=c23 -o what what.c
>>>>>> what.c:2:58: warning: for loop has empty body [-Wempty-body]
>>>>>> 2 | int main(void) { for (unsigned int k = 0; k != 1; k += 2); return 0; }
>>>>>> | ^
>>>>>> what.c:2:58: note: put the semicolon on a separate line to silence this warning
>>>>>> 1 warning generated.
>>>>>> term% ./what
>>>>>> Hello, World!
>>>>>> term%
>>>>>> ```
>>>>>
>>>>>I see the same behavior.
>>>>>
>>>>>The following largely repeats what I've written previously in
>>>>>this thread.
>>>>>
>>>>>Apparently the authors of clang decided that this statement in N3220
>>>>>6.8.6.p4:
>>>>>
>>>>> An iteration statement may be assumed by the implementation to
>>>>> terminate if its controlling expression is not a constant
>>>>> expression, ...
>>>>>
>>>>>means that a program that violates that assumption has undefined
>>>>>behavior. I intensely dislike both the rule and the way it's stated,
>>>>>but I agree that the conclusion that the behavior is undefined is
>>>>>a reasonable one.
>>>>
>>>> I think the behavior is technical "unspecified" in the sense of
>>>> the C standard, but yes, this is the important bit. The
>>>> controlling expresion is not constant, and the loop doesn't meet
>>>> any of the other criteria set forth in sec 6.8.6 para 4 for,
>>>> therefore, the translator may assume it terminates (it is
>>>> unspecified whether or not it does; either behavior is correct.
>>>> GCC, for example, appears not to make the same assumption).
>>>
>>>Why do you think the behavior is unspecified rather that undefined?
>>>
>>>Unspecified behavior is defined as: "behavior, that results from
>>>the use of an unspecified value, or other behavior upon which
>>>this document provides two or more possibilities and imposes
>>>no further requirements on which is chosen in any instance".
>>>(Implementation-defined behavior differs from unspecified behavior
>>>in that the implementation must document how the choice is made.)
>>>
>>>What are the "two more more possibilities" in this case?
>>
>> The two choices are that the implementation may assume the loop
>> terminates, or it may not, but it doesn't say which. I don't
>> think that the language permits it to be UB. But I could be
>> wrong. It's a bit of a distinction without a difference as far
>> as the outcome is concerned.
>
>No, those are not the two choices. An assumption made by an
>implementation is not behavior ("external appearance or action").
>An implementation might invoke some behavior as a result of some
>assumption.
>
>If a loop doesn't terminate and the implementation assumes that
>it does, the standard says nothing about the resulting behavior.
>It doesn't provide two or more options for the actual behavior.
>That's classic UB.
>
>We've seen cases here where the actual behavior is falling through
>into a function that's never called. That's certainly not a
>possibility provided by the standard.
Ok, fair point.
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-06-12 11:37 +0200 |
| Subject | Re: Constants and undefined behavior |
| Message-ID | <110gk13$21vi3$3@dont-email.me> |
| In reply to | #399926 |
On 12/06/2026 01:46, Dan Cross wrote:
> In article <110fgbi$1qf9f$1@kst.eternal-september.org>,
> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>> cross@spitfire.i.gajendra.net (Dan Cross) writes:
>>> In article <110cre9$13aa9$1@kst.eternal-september.org>,
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>>> cross@spitfire.i.gajendra.net (Dan Cross) writes:
>>>> [...]
>>>>> I see you did not read the other messages in the (sub)thread,
>>>>> but ok, here it is again, in C:
>>>>>
>>>>> ```
>>>>> term% cat what.c
>>>>> #include <stdio.h>
>>>>> int main(void) { for (unsigned int k = 0; k != 1; k += 2); return 0; }
>>>>> void hello(void) { printf("Hello, World!\n"); }
>>>>> term% clang --version | sed 1q
>>>>> clang version 22.1.6
>>>>> term% clang -Wall -pedantic -pedantic-errors -O1 -std=c23 -o what what.c
>>>>> what.c:2:58: warning: for loop has empty body [-Wempty-body]
>>>>> 2 | int main(void) { for (unsigned int k = 0; k != 1; k += 2); return 0; }
>>>>> | ^
>>>>> what.c:2:58: note: put the semicolon on a separate line to silence this warning
>>>>> 1 warning generated.
>>>>> term% ./what
>>>>> Hello, World!
>>>>> term%
>>>>> ```
>>>>
>>>> I see the same behavior.
>>>>
>>>> The following largely repeats what I've written previously in
>>>> this thread.
>>>>
>>>> Apparently the authors of clang decided that this statement in N3220
>>>> 6.8.6.p4:
>>>>
>>>> An iteration statement may be assumed by the implementation to
>>>> terminate if its controlling expression is not a constant
>>>> expression, ...
>>>>
>>>> means that a program that violates that assumption has undefined
>>>> behavior. I intensely dislike both the rule and the way it's stated,
>>>> but I agree that the conclusion that the behavior is undefined is
>>>> a reasonable one.
>>>
>>> I think the behavior is technical "unspecified" in the sense of
>>> the C standard, but yes, this is the important bit. The
>>> controlling expresion is not constant, and the loop doesn't meet
>>> any of the other criteria set forth in sec 6.8.6 para 4 for,
>>> therefore, the translator may assume it terminates (it is
>>> unspecified whether or not it does; either behavior is correct.
>>> GCC, for example, appears not to make the same assumption).
>>
>> Why do you think the behavior is unspecified rather that undefined?
>>
>> Unspecified behavior is defined as: "behavior, that results from
>> the use of an unspecified value, or other behavior upon which
>> this document provides two or more possibilities and imposes
>> no further requirements on which is chosen in any instance".
>> (Implementation-defined behavior differs from unspecified behavior
>> in that the implementation must document how the choice is made.)
>>
>> What are the "two more more possibilities" in this case?
>
> The two choices are that the implementation may assume the loop
> terminates, or it may not, but it doesn't say which. I don't
> think that the language permits it to be UB. But I could be
> wrong. It's a bit of a distinction without a difference as far
> as the outcome is concerned.
>
> - Dan C.
>
I think perhaps there is both undefined and unspecified aspects here.
The implementation may assume the loop terminates - that means, to me,
that there are no requirements for what happens if the loop does not
terminate. Not terminating would be UB.
However, I don't support clang's reasoning after that in this case. As
I see it, a compiler can reason that the loop terminates and then
executes "return 0;" because the non-terminating situation is UB and
cannot occur. Thus it can skip the loop and go straight to "return 0;".
Alternatively, it can reason that the non-terminating situation is UB
and we don't care what happens if it does not terminate - so "return 0;"
would be fine in that case too, simplifying the generated code.
But it seems that clang is reasoning that it can assume the loop
terminates, and it can prove that the loop does not terminate, and this
contradiction means that anything is allowed (including skipping all
code generation). The code has two conflicting semantics - it is an
infinite loop, and it is a terminating loop. I think the standards say
that the compiler /may/ consider the terminating loop interpretation as
correct, thus giving just "return 0;", or it may choose not to consider
that it terminates, and generate an infinite loop. Clang appears to
think that it can pick both options at once, which would give
contradictory behaviour, and therefore jump straight to UB.
I would say that the best behaviour for a compiler here would be to give
a warning, then it should pick one or the other defined behaviours.
(gcc picks the infinite loop, but does not give any warning.) I cannot
say for sure that clang's behaviour is incorrect - but it is certainly
very unhelpful and poor quality of implementation.
(I also think that it makes sense for compilers to use the "ud2" or
similar "undefined behaviour" trap instructions in cases where they know
an execution path is definitely UB and doing so does not affect the
efficiency of non-UB paths.)
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-06-02 05:35 -0700 |
| Message-ID | <10vmimv$2tjoi$3@kst.eternal-september.org> |
| In reply to | #399608 |
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
> On 2026-06-01 00:54, Keith Thompson wrote:
>>> [...]
>> Yes, a compiler can reduce (a + b) * 0 to just 0. But it's not
>> required to do so, and (INT_MAX + 1) * 0 still has undefined
>> behavior. Undefined behavior is determined by the rules of the
>> abstract machine *without* any adjustments permitted by the as-if
>> rule.
>
> This is something I really don't get in the actual C-logic...
>
> Using constants that can be determined at compile time is UB here,
> despite the '* 0' mathematically indicating an IMO clear semantics,
> but using variables is only UB possibly at runtime? And despite all
> that the latter might not even get triggered because it's probably
> optimized away? - I can't help, this sounds really crude.
>
> Is there any rationale from the _software designer_'s perspective?
In the abstract machine, every operator and subexpression is
evaluated (barring things like "||", "&&", and "?:"). (INT_MAX + 1)
has undefined behavior due to overflow, therefore any expression
that has (INT_MAX + 1) as a subexpression has undefined behavior.
Replacing (expr * 0) by 0 is an optimization, and optimizations
are *optional*. A naive implementation could generate code that
peforms the addition and the muliplication by 0; if the addition
traps, it traps.
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.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-06-02 06:29 -0700 |
| Message-ID | <86ecipcbqa.fsf@linuxsc.com> |
| In reply to | #399618 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> 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.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-06-02 16:10 +0200 |
| Message-ID | <10vmo8n$2ruaa$3@dont-email.me> |
| In reply to | #399625 |
On 02/06/2026 15:29, Tim Rentsch wrote: > Keith Thompson <Keith.S.Thompson+u@gmail.com> 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. My testing shows all versions of gcc that I tested on godbolt gave a warning, even without any options. I don't believe that INT_MAX can have any type suffixes that would avoid the overflow. What version of gcc and/or flags let that case label pass without a diagnostic? (I don't know if Keith is correct about it being a constraint violation - I have not looked at the details there.)
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-06-02 15:29 -0700 |
| Message-ID | <10vnlgu$382un$2@kst.eternal-september.org> |
| In reply to | #399625 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> 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?
$ cat c.c
#include <limits.h>
int main(void) {
switch (0) {
case (INT_MAX + 1) * 0:
break;
}
}
$ gcc -std=c17 -pedantic-errors -c c.c
c.c: In function ‘main’:
c.c:4:23: warning: integer overflow in expression of type ‘int’ results in ‘-2147483648’ [-Woverflow]
4 | case (INT_MAX + 1) * 0:
| ^
c.c:4:9: error: overflow in constant expression [-Woverflow]
4 | case (INT_MAX + 1) * 0:
| ^~~~
$
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.
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.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-06-05 06:41 -0700 |
| Message-ID | <86bjdpayv0.fsf@linuxsc.com> |
| In reply to | #399652 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > >> Keith Thompson <Keith.S.Thompson+u@gmail.com> 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.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-06-05 11:24 -0700 |
| Message-ID | <10vv49k$1aoa2$4@kst.eternal-september.org> |
| In reply to | #399748 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> 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.
Why?
You made a statement, "gcc disagrees with you". I demonstrated,
in text that you snipped, that gcc does in fact agree with me.
You were wrong. I don't know the basis of your error, so I asked.
Or maybe I'm missing something, and you had a valid point that I
didn't understand.
You're not required to answer my question, which I think was
an extremely reasonable one, but quoting it and then explicitly
refusing to answer it is pointlessly rude.
I'd like to know whether you still think you were right. If so,
I'd like to see your explanation. If not, an admission that you
made a mistake would be appreciated. But I expect neither from you.
[SNIP]
> 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.
The actual text of the standard implies that 42 is not an expression.
I rely on the obvious intent to conclude that it is.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-06-08 08:35 -0700 |
| Message-ID | <86y0gp82pd.fsf@linuxsc.com> |
| In reply to | #399756 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > >> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: >> >>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes: >>> >>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> 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. > > Why? gcc is not authoritative. I didn't want to get into an argument about whether gcc is conforming, or which version of gcc was used, or any similar distractions. The C standard /is/ authoritative, and I thought it would save time to cut to the chase. > You made a statement, "gcc disagrees with you". I demonstrated, > in text that you snipped, that gcc does in fact agree with me. No, you didn't. > You were wrong. No, I wasn't. Your testing was faulty. > I don't know the basis of your error, so I asked. > Or maybe I'm missing something, and you had a valid point that I > didn't understand. I'm offended that you think I have an obligation to remedy your habit of lazy thinking, especially when as here the answer was staring you right in the face, and you simply ignored it. > You're not required to answer my question, which I think was > an extremely reasonable one, but quoting it and then explicitly > refusing to answer it is pointlessly rude. I wasn't refusing to answer. What I was doing was trying to answer the original question, and answer it in a way that wouldn't get lost in pointless bickering. Silly me. > I'd like to know whether you still think you were right. If so, > I'd like to see your explanation. If not, an admission that you > made a mistake would be appreciated. But I expect neither from you. I'd like to know why you ignored my explanation, based directly on text from the C standard, about why an implementation is allowed to process the code in question, without giving a diagnostic, and still be conforming. An explanation that Dan Cross agreed with, even if he may not like the consequences. In investigating this question, I have run compilations using multiple versions of gcc, on two different platforms. I have looked carefully through the gcc man page. I have also run compilations using multiple versions of clang, on two different platforms. After doing all that, I ran compilations using godbolt, so I could check the latest, or maybe almost latest, versions of gcc and clang. All the different versions of gcc and clang that I have tried support my hypothesis that gcc (and now also clang) interpret the C standard so as to conclude that conforming to the C standard need not require a diagnostic for situations like the code under discussion.. I'd like to ask you to do two things. First, read through the reasoning given in my previous post, try to assess whether that reasoning is sound, and post the results of yours contemplations. Second, look again at the question of whether gcc (and also clang, if you're up to it) support the hypothesis that a conforming implementation need not give a diagnostic for code like that under discussion. See if you can find a way of framing the question that supports my statement, rather than simply looking for one that supports your preconceived ideas. Post the results of your investigations, both what other experiments you tried, and what your assessment is of the results you got. Do these two things and I will endeavor to explain my views on the questions you have raised here, if such explanations are still needed after your further examinations and comments. > [SNIP] > >> 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. > > The actual text of the standard implies that 42 is not an expression. > I rely on the obvious intent to conclude that it is. Now it is you who is changing the subject. Besides not being on point to the question being considered, it's a silly argument, and I would hope you are smart enough to realize that. However, if you do what I have asked in the previous paragraph, I can try to explain why I think your views on this unrelated matter are wrongheaded.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-06-08 17:33 +0000 |
| Message-ID | <1106udm$jmf$1@reader1.panix.com> |
| In reply to | #399791 |
In article <86y0gp82pd.fsf@linuxsc.com>,
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>
>>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>>
>>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> 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.
>>
>> Why?
>
>gcc is not authoritative.
You, Tim, wrote the words, "gcc disagrees with you."
If you didn't want to bring GCC into it, because it is not
authoritative (which is true), then why did you mention it in
the first place?
>I didn't want to get into an argument
>about whether gcc is conforming, or which version of gcc was used,
>or any similar distractions.
You opened that door and walked through it.
>The C standard /is/ authoritative,
>and I thought it would save time to cut to the chase.
Then you should have done that from the start, and not mentioned
GCC.
>> [snip]
>> I'd like to know whether you still think you were right. If so,
>> I'd like to see your explanation. If not, an admission that you
>> made a mistake would be appreciated. But I expect neither from you.
>
>I'd like to know why you ignored my explanation, based directly on
>text from the C standard, about why an implementation is allowed to
>process the code in question, without giving a diagnostic, and
>still be conforming. An explanation that Dan Cross agreed with,
>even if he may not like the consequences.
I am mystified as to why you are bringing my name into this, and
why you think "I may not like the consequences", or even what
that means. In any event, you are evidently laboring under some
assumption about what I think about this matter that is probably
incorrect.
Because I am not you, I cannot know this for a fact, let alone
why it may be. Regardless, I suggest you don't do that, or at a
minimum seek clarity from the referent of your assumptions,
before making claims about they may think.
>In investigating this question, I have run compilations using
>multiple versions of gcc, on two different platforms. I have looked
>carefully through the gcc man page. I have also run compilations
>using multiple versions of clang, on two different platforms. After
>doing all that, I ran compilations using godbolt, so I could check
>the latest, or maybe almost latest, versions of gcc and clang. All
>the different versions of gcc and clang that I have tried support my
>hypothesis that gcc (and now also clang) interpret the C standard so
>as to conclude that conforming to the C standard need not require a
>diagnostic for situations like the code under discussion..
It appears that you are appealing to a certain kind of semantic
precision, that is itself based on a number of assumptions that
are unstated, but that are implicit in your writing. Further,
you give every indication of believing that a reader should
simply intuitively know.
In fact, both GCC and clang (the versions I tried on the
platforms I tried on) emit a diagnostic for the code under
consideration. Your assertion appears to be that that is
unrelated to the constraint in section 6.6 para 4, which seems
accurate.
But you did not say that: instead, you just made a vague
statement that "gcc disagrees with you." That's not useful, and
no one can reasonably know what you meant unless you elaborated
on it.
When it was pointed out to you that in fact GCC generates a
diagnostic, you had an opportunity to clarify that it was not in
response to the aforementioned constraint violation. You chose
not to do so, and instead of arrogantly accuse others of
laziness and a lack of willingness to understand.
Insisting that your readers adhere to some arbitrary level of
semantic precision you seem to fancy yourself expressing is not
actually a sign of true expertise. Real expertise is most
readily demonstrated through effective communication.
>I'd like to ask you to do two things. First, read through the
>reasoning given in my previous post, try to assess whether that
>reasoning is sound, and post the results of yours contemplations.
>
>Second, look again at the question of whether gcc (and also clang,
>if you're up to it) support the hypothesis that a conforming
>implementation need not give a diagnostic for code like that under
>discussion. See if you can find a way of framing the question that
>supports my statement, rather than simply looking for one that
>supports your preconceived ideas. Post the results of your
>investigations, both what other experiments you tried, and what your
>assessment is of the results you got.
>
>Do these two things and I will endeavor to explain my views on the
>questions you have raised here, if such explanations are still
>needed after your further examinations and comments.
It is rather cavalier to make imperative statements to others
regarding how they must spend their time.
>> [SNIP]
>>
>>> 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.
>>
>> The actual text of the standard implies that 42 is not an expression.
>> I rely on the obvious intent to conclude that it is.
>
>Now it is you who is changing the subject. Besides not being on
>point to the question being considered, it's a silly argument, and I
>would hope you are smart enough to realize that. However, if you do
>what I have asked in the previous paragraph, I can try to explain
>why I think your views on this unrelated matter are wrongheaded.
Is it a silly argument?
Perhaps Keith has some reason for suggesting that such an
interpretation is be valid. I'm not aware of what that might
be, but I suspect you are not, either. But without even knowing
what the argument is, how would you know?
You are the one admonishing others to look at the letter of the
standard ("My conclusions are based on what the C standard
actually says..."), yet here you dismiss as "a silly argument",
a thing brought up by someone who has demonstrated that they
generally know what they're talking about, and you have done so
without even bothering to ask what they might be refering to.
In fact, I think this fits a pattern of behavior I observe from
you fairly consistently. You decide on an interpretation,
declare it correct, and appear to scoff at anyone else who does
not immediately share that interpretation as being "lazy" or
worse.
Ironically, you yourself do not do well when you are shown to be
wrong about something; cf your bizarre statement about Rust not
being strongly typed. This does not do well for your
credibility; everyone makes mistakes now and again, and you are
no different, but your seeming inability to admit to it when it
is obvious decreases faith in your interpretations when they are
not obvious.
You would do well to express more humility, and consider how
others might perceive you based on the way you talk to them.
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-06-09 00:54 -0700 |
| Message-ID | <86pl2087z3.fsf@linuxsc.com> |
| In reply to | #399795 |
cross@spitfire.i.gajendra.net (Dan Cross) writes: > In article <86y0gp82pd.fsf@linuxsc.com>, > Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: [...] >> I'd like to know why you ignored my explanation, based directly on >> text from the C standard, about why an implementation is allowed to >> process the code in question, without giving a diagnostic, and >> still be conforming. An explanation that Dan Cross agreed with, >> even if he may not like the consequences. > > I am mystified as to why you are bringing my name into this, and > why you think "I may not like the consequences", or even what > that means. In any event, you are evidently laboring under some > assumption about what I think about this matter that is probably > incorrect. In a response to another posting of mine, you wrote this: > But as it happens, I think I can see how your interpretation may > be valid: if, as a result of UB, the expression evaluates to "0" > (or 12 or something simiilar) that _is_ representable, then > there _is no constraint violation_ and so no diagnostic is > required. > > I do not believe that that is the intent. But it _is_ > conformant with the text of the standard. I based my statement that begins "An explanation that Dan Cross agreed with, ..." on those two paragraphs.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-06-09 10:08 +0000 |
| Message-ID | <1108om9$89f$1@reader1.panix.com> |
| In reply to | #399807 |
In article <86pl2087z3.fsf@linuxsc.com>, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >cross@spitfire.i.gajendra.net (Dan Cross) writes: > >> In article <86y0gp82pd.fsf@linuxsc.com>, >> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > >[...] > >>> I'd like to know why you ignored my explanation, based directly on >>> text from the C standard, about why an implementation is allowed to >>> process the code in question, without giving a diagnostic, and >>> still be conforming. An explanation that Dan Cross agreed with, >>> even if he may not like the consequences. >> >> I am mystified as to why you are bringing my name into this, and >> why you think "I may not like the consequences", or even what >> that means. In any event, you are evidently laboring under some >> assumption about what I think about this matter that is probably >> incorrect. > >In a response to another posting of mine, you wrote this: > >> But as it happens, I think I can see how your interpretation may >> be valid: if, as a result of UB, the expression evaluates to "0" >> (or 12 or something simiilar) that _is_ representable, then >> there _is no constraint violation_ and so no diagnostic is >> required. >> >> I do not believe that that is the intent. But it _is_ >> conformant with the text of the standard. > >I based my statement that begins "An explanation that Dan Cross >agreed with, ..." on those two paragraphs. Nothing in those two paragraphs asserts that I am unhappy with the consequences; I neither like nor dislike the "consequences." I simply don't think that was the intent of people who wrote the standard. Before asserting a subjective interpretation of what someone else feels about a thing, you should seek to clarify if what you intent to say is accurate. Better yet, just don't do it. And of course, what I think about the matter is irrelevant to what you wrote to Keith, which I found sufficiently distasteful that I rather wish you hadn't mentioned my name in it at all. The rest of my earlier response stands. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-06-08 13:40 -0700 |
| Message-ID | <11079cs$3grso$1@kst.eternal-september.org> |
| In reply to | #399791 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> 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.
What question? I made a statement.
>> Why?
>
> gcc is not authoritative. I didn't want to get into an argument
> about whether gcc is conforming, or which version of gcc was used,
> or any similar distractions. The C standard /is/ authoritative,
> and I thought it would save time to cut to the chase.
I never said gcc is authoritative. *You* brought gcc into the
discussion.
It is a fact that gcc issues a diagnostic for that case label.
It is a fact that it's a non-fatal warning with "-pedantic" and a
fatal error with "-pedantic-errors", which implies, as I understand
it, that the authors of gcc believe that the diagnostic is required
by the standard.
>> You made a statement, "gcc disagrees with you". I demonstrated,
>> in text that you snipped, that gcc does in fact agree with me.
>
> No, you didn't.
Yes, I did.
>> You were wrong.
>
> No, I wasn't. Your testing was faulty.
Yes, you were. My testing was not faulty.
What exactly did you mean by "gcc disagrees with you"? I
think it's sufficiently obvious that gcc does not have opinions,
so you presumably were speaking figuratively in some sense.
Do you not see the same diagnostic I saw?
>> I don't know the basis of your error, so I asked.
>> Or maybe I'm missing something, and you had a valid point that I
>> didn't understand.
>
> I'm offended that you think I have an obligation to remedy your
> habit of lazy thinking, especially when as here the answer was
> staring you right in the face, and you simply ignored it.
OK. I'm offended by your superior attitude. I'm offended by your
refusal to consider that you might have made a mistake. I'm offended
by your refusal to explain what you meant by an unclear statement
after I repeatedly ask you to do so. I'm offended by your apparent
assumption that if the rest of us just *think really hard*, we'll
inevitably agree with you.
>> You're not required to answer my question, which I think was
>> an extremely reasonable one, but quoting it and then explicitly
>> refusing to answer it is pointlessly rude.
>
> I wasn't refusing to answer. What I was doing was trying to
> answer the original question, and answer it in a way that wouldn't
> get lost in pointless bickering. Silly me.
I'm assuming that by "the original question", you're referring to my
*statement* that a diagnostic is required for the above case label.
If you have some other "original question" in mind, please specify
it. Please do not insult me by assuming that I'll know exactly
what you mean if I just reread what you wrote and think hard enough.
If you were trying to answer the "original question", you failed.
You expressed your supposed disagrement by asserting, without
further explanation, that gcc disagrees with me -- when, in fact,
it does not, and when gcc's behavior is not directly relevant to
the original statement anyway (since, as you correctly point out,
gcc is not authoritative).
>> I'd like to know whether you still think you were right. If so,
>> I'd like to see your explanation. If not, an admission that you
>> made a mistake would be appreciated. But I expect neither from you.
>
> I'd like to know why you ignored my explanation, based directly on
> text from the C standard, about why an implementation is allowed to
> process the code in question, without giving a diagnostic, and
> still be conforming. An explanation that Dan Cross agreed with,
> even if he may not like the consequences.
That explanation is not relevant to your claim that gcc disagrees
with me, which is what I asked you about.
> In investigating this question, I have run compilations using
> multiple versions of gcc, on two different platforms. I have looked
> carefully through the gcc man page. I have also run compilations
> using multiple versions of clang, on two different platforms. After
> doing all that, I ran compilations using godbolt, so I could check
> the latest, or maybe almost latest, versions of gcc and clang. All
> the different versions of gcc and clang that I have tried support my
> hypothesis that gcc (and now also clang) interpret the C standard so
> as to conclude that conforming to the C standard need not require a
> diagnostic for situations like the code under discussion..
You've told us what you concluded from your compilations using godbolt.
You haven't told us what those compilations actually told you.
On the off chance that you're willing to answer a straightforward
question:
Here's one result I got on my system:
$ gcc16 --version | head -n 1
gcc16 (GCC) 16.1.0
$ cat c.c
#include <limits.h>
int main(void) {
switch(0) {
case (INT_MAX + 1) * 0:
break;
}
}
$ gcc16 -std=c23 -pedantic-errors -c c.c
c.c: In function ‘main’:
c.c:4:23: warning: integer overflow in expression of type ‘int’ results in ‘-2147483648’ [-Woverflow]
4 | case (INT_MAX + 1) * 0:
| ^
c.c:4:9: error: overflow in constant expression [-Woverflow]
4 | case (INT_MAX + 1) * 0:
| ^~~~
$
gcc emitted a fatal error message on that case label. Have you
seen any version of gcc, either on your system or on godbolt,
*not* issue a fatal error message when invoked on that source with
"-std=cNN -pedantic-errors" (NN=23, or any valid value you like)?
If so, have you seen it not at least issue a warning?
If not, what is the basis for your claim that gcc disagrees with me?
It's conceivable that what you meant is that gcc happens to issue
a diagnostic, but is not required to. If so, then (a) that's
sufficiently subtle that any reasonable person would have explained
that point, and (b) given that gcc produces a diagnostic, I see no
basis to assume that gcc "thinks" it's not required to do so.
> I'd like to ask you to do two things. First, read through the
> reasoning given in my previous post, try to assess whether that
> reasoning is sound, and post the results of yours contemplations.
> Second, look again at the question of whether gcc (and also clang,
> if you're up to it) support the hypothesis that a conforming
> implementation need not give a diagnostic for code like that under
> discussion. See if you can find a way of framing the question that
> supports my statement, rather than simply looking for one that
> supports your preconceived ideas. Post the results of your
> investigations, both what other experiments you tried, and what your
> assessment is of the results you got.
You made a very simple claim, that gcc disagrees with me. I'm asking
you about *that statement*. Do you still assert that gcc disagrees
with me? (That is not a question about the C standard.)
> Do these two things and I will endeavor to explain my views on the
> questions you have raised here, if such explanations are still
> needed after your further examinations and comments.
>
>> [SNIP]
>>
>>> 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.
>>
>> The actual text of the standard implies that 42 is not an expression.
>> I rely on the obvious intent to conclude that it is.
>
> Now it is you who is changing the subject. Besides not being on
> point to the question being considered, it's a silly argument, and I
> would hope you are smart enough to realize that. However, if you do
> what I have asked in the previous paragraph, I can try to explain
> why I think your views on this unrelated matter are wrongheaded.
Please be less condescending.
Leaving gcc aside, my original statement was that a case label like:
case (INT_MAX + 1) * 0:
is a constraint violation (and therefore that it requires a diagnostic).
It's possible that I'm mistaken on that point. The constraint I claim
it violates is that "Each constant expression shall evaluate to a
constant that is in the range of representable values for its type."
We could have discussed that much more briefly if you hadn't dragged
gcc into it.
I acknowledge that it can also be reasonably argued that the
expression as a whole *can*, for a particular implementation, yield
a result of 0, and therefore that a diagnostic is not required *for
such an implementation*.
The committee response to C90 DR #031 contradicts that argument:
case (INT_MAX*4)/4: is a constraint violation.
When subclause 6.4 says on page 55, lines 11-12:
Each constant expression shall evaluate to a constant that is in the
range of representable values for its type.
the Committee's judgement of the intent is that the
``representable'' requirement applies to each subexpression of
a constant expression, as shown in the third example. A constant
expression is meant as defined by the syntax rules.
My judgement of the intent agrees with the Committee's, and, as
far as I can tell, with gcc's.
(I do think that the wording in the standard could and should be
improved.)
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-06-08 14:05 -0700 |
| Subject | Meaning of "expression" |
| Message-ID | <1107aq2$3grso$2@kst.eternal-september.org> |
| In reply to | #399756 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
[...]
> The actual text of the standard implies that 42 is not an expression.
> I rely on the obvious intent to conclude that it is.
I made the above statement to demonstrate that just following the exact
wording of the standard, without thinking about the (sometimes unclear)
intent behind it, can lead to absurd results.
I've discussed this particular glitch before, but it's been a while.
N3220 6.5.1 says:
An *expression* is a sequence of operators and operands that
specifies computation of a value, or that designates an object
or a function, or that generates side effects, or that performs
a combination thereof.
I believe the wording is unchanged from C90 up to the latest C202y
draft. Since the word "expression" is in italics, this is the
standard's definition of the word.
This is a flawed definition. The terms "operator" and "operand"
are defined in 6.4.6:
*punctuator: one of
[ ] ( )
[snip]
A punctuator is a symbol that has independent syntactic and semantic
significance. Depending on context, it may specify an operation to
be performed (which in turn may yield a value or a function
designator, produce a side effect, or some combination thereof) in
which case it is known as an *operator* (other forms of operator also
exist in some contexts). An *operand* is an entity on which an
operator acts.
Consider this expression statement:
42;
Is `42` an expression? Clearly it's intended to be, but there is no
operator, and therefore there is no operand, so it doesn't meet the
standard's definition of the word "expression".
For that matter, consider:
(void)0;
It's "obvious" that `(void)0` is an expression. It consists of one
operator `(void)` and one operand `0` (I'll ignore the fact that
the definition uses plurals for both), but it does not specify
computation of a value, or designate an object or a function,
or generates side effects, or perform a combination thereof.
The fact that the standard's definition of "expression" is flawed is
not much of a problem in practice. Virtually everyone, implementers
and programmers, assumes the obvious intent. Nobody believes that
`42` isn't an expression. But it is my strongly held opinion that
the wording should be improved in a future edition of the standard.
I think it should say something to the effect that the meaning
of the term "expression" is defined by the grammar. The current
wording that claims to be the definition of the term could, with
a few tweaks, still be turned into a valid normative statement
*about* expressions.
I have a similar issue with the standard's definition of "value":
"precise meaning of the contents of an object when interpreted as
having a specific type". It's obvious that the result of evaluating
a non-void expression (such as the infamous `42`) is a "value",
but the definition implies that a "value" can only be the meaning
of the contents of an object. Nobody is actually misled by the
current definition, but it should be improved.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-06-09 15:17 +0200 |
| Subject | Expression statements (was Re: Meaning of "expression") |
| Message-ID | <11093p9$1nauc$1@dont-email.me> |
| In reply to | #399799 |
On 2026-06-08 23:05, Keith Thompson wrote: > [...] > I've discussed this particular glitch before, but it's been a while. > > N3220 6.5.1 says: > > An *expression* is a sequence of operators and operands that > specifies computation of a value, or that designates an object > or a function, or that generates side effects, or that performs > a combination thereof. > > I believe the wording is unchanged from C90 up to the latest C202y > draft. Since the word "expression" is in italics, this is the > standard's definition of the word. > > This is a flawed definition. The terms "operator" and "operand" > are defined in 6.4.6: > > *punctuator: one of > [ ] ( ) > [snip] > > A punctuator is a symbol that has independent syntactic and semantic > significance. Depending on context, it may specify an operation to > be performed (which in turn may yield a value or a function > designator, produce a side effect, or some combination thereof) in > which case it is known as an *operator* (other forms of operator also > exist in some contexts). An *operand* is an entity on which an > operator acts. > > Consider this expression statement: > > 42; > > Is `42` an expression? Clearly it's intended to be, but there is no > operator, and therefore there is no operand, so it doesn't meet the > standard's definition of the word "expression". Above you used the term "expression statement", and then compare the "42" to an "expression". I know from my earlier C-days that '42;' is a valid statement, and so the term "expression statement" makes sense to me. I know from various languages' syntax definitions that a number like '42' is a sensible form for an expression (and no operators required). It's also depending on the context. Where expressions may be written (and where not) depends on the concrete language; syntactically and also semantically. Usually I'd expect above "expression-statement" to serve some purpose, semantically. I don't recall that in "C" such an expression-statement would serve any purpose. (Or that they'd show any observable behavior, if that term fits the C-parlance better?) Or do these stand-alone values (the "expression-statement") have some practically useful semantics? In other languages such stand-alone values serve a purpose; e.g. they may determine the result value of a block that can then be used in an outer context; but in "C" such constructs are obviously not possible. What purpose serve such stand-alone numbers in places where statements are expected? > [...] > > The fact that the standard's definition of "expression" is flawed is > not much of a problem in practice. Virtually everyone, implementers > and programmers, assumes the obvious intent. Nobody believes that > `42` isn't an expression. But it is my strongly held opinion that > the wording should be improved in a future edition of the standard. > > I think it should say something to the effect that the meaning > of the term "expression" is defined by the grammar. The current > wording that claims to be the definition of the term could, with > a few tweaks, still be turned into a valid normative statement > *about* expressions. > > I have a similar issue with the standard's definition of "value": > "precise meaning of the contents of an object when interpreted as > having a specific type". It's obvious that the result of evaluating > a non-void expression (such as the infamous `42`) is a "value", > but the definition implies that a "value" can only be the meaning > of the contents of an object. Nobody is actually misled by the > current definition, but it should be improved. Janis
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-06-09 14:53 +0100 |
| Subject | Re: Expression statements (was Re: Meaning of "expression") |
| Message-ID | <11095su$1obc$1@dont-email.me> |
| In reply to | #399820 |
On 09/06/2026 14:17, Janis Papanagnou wrote:
> On 2026-06-08 23:05, Keith Thompson wrote:
>> [...]
>> I've discussed this particular glitch before, but it's been a while.
>>
>> N3220 6.5.1 says:
>>
>> An *expression* is a sequence of operators and operands that
>> specifies computation of a value, or that designates an object
>> or a function, or that generates side effects, or that performs
>> a combination thereof.
>>
>> I believe the wording is unchanged from C90 up to the latest C202y
>> draft. Since the word "expression" is in italics, this is the
>> standard's definition of the word.
>>
>> This is a flawed definition. The terms "operator" and "operand"
>> are defined in 6.4.6:
>>
>> *punctuator: one of
>> [ ] ( )
>> [snip]
>> A punctuator is a symbol that has independent syntactic and semantic
>> significance. Depending on context, it may specify an operation to
>> be performed (which in turn may yield a value or a function
>> designator, produce a side effect, or some combination thereof) in
>> which case it is known as an *operator* (other forms of operator
>> also
>> exist in some contexts). An *operand* is an entity on which an
>> operator acts.
>>
>> Consider this expression statement:
>>
>> 42;
>>
>> Is `42` an expression? Clearly it's intended to be, but there is no
>> operator, and therefore there is no operand, so it doesn't meet the
>> standard's definition of the word "expression".
>
> Above you used the term "expression statement", and then compare the
> "42" to an "expression".
>
> I know from my earlier C-days that '42;' is a valid statement, and so
> the term "expression statement" makes sense to me.
>
> I know from various languages' syntax definitions that a number like
> '42' is a sensible form for an expression (and no operators required).
> It's also depending on the context. Where expressions may be written
> (and where not) depends on the concrete language; syntactically and
> also semantically.
>
> Usually I'd expect above "expression-statement" to serve some purpose,
> semantically. I don't recall that in "C" such an expression-statement
> would serve any purpose. (Or that they'd show any observable behavior,
> if that term fits the C-parlance better?)
>
> Or do these stand-alone values (the "expression-statement") have some
> practically useful semantics?
>
> In other languages such stand-alone values serve a purpose; e.g. they
> may determine the result value of a block that can then be used in an
> outer context; but in "C" such constructs are obviously not possible.
>
> What purpose serve such stand-alone numbers in places where statements
> are expected?
I think it is just difficult for the syntax to ban certain expressons
and not others. How would you express that in the grammar?
If you ramp up the warnings, then you'll get messages like 'statement
with no effect' or 'computed value not used', since sometimes there are
side-effects that are needed:
f() + g();
f() and g() both do something, but nothing is done with their sum.
In my projects, such standalone expressions are always a hard error. The
main exceptions include (using C syntax):
f();
++a;
a = b;
These are expressions that can return values, but that can sensibly be
used standalone too. (I don't support value-returning compound assignments.)
(I first introduced this check because in the past, if I'd been writing
some C, I might write 'a = b' instead of 'a := b'. The first does
nothing (compares then discards result), but it is not what I'd intended.)
Anyway, I don't have it as a syntax violation either.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-06-09 16:30 +0200 |
| Subject | Re: Expression statements (was Re: Meaning of "expression") |
| Message-ID | <110981v$1nauc$2@dont-email.me> |
| In reply to | #399821 |
On 2026-06-09 15:53, Bart wrote: > On 09/06/2026 14:17, Janis Papanagnou wrote: >> On 2026-06-08 23:05, Keith Thompson wrote: >>> [...] >>> I've discussed this particular glitch before, but it's been a while. >>> >>> N3220 6.5.1 says: >>> >>> An *expression* is a sequence of operators and operands that >>> specifies computation of a value, or that designates an object >>> or a function, or that generates side effects, or that performs >>> a combination thereof. >>> >>> I believe the wording is unchanged from C90 up to the latest C202y >>> draft. Since the word "expression" is in italics, this is the >>> standard's definition of the word. >>> >>> This is a flawed definition. The terms "operator" and "operand" >>> are defined in 6.4.6: >>> >>> *punctuator: one of >>> [ ] ( ) >>> [snip] >>> A punctuator is a symbol that has independent syntactic and >>> semantic >>> significance. Depending on context, it may specify an operation to >>> be performed (which in turn may yield a value or a function >>> designator, produce a side effect, or some combination thereof) in >>> which case it is known as an *operator* (other forms of operator >>> also >>> exist in some contexts). An *operand* is an entity on which an >>> operator acts. >>> >>> Consider this expression statement: >>> >>> 42; >>> >>> Is `42` an expression? Clearly it's intended to be, but there is no >>> operator, and therefore there is no operand, so it doesn't meet the >>> standard's definition of the word "expression". >> >> Above you used the term "expression statement", and then compare the >> "42" to an "expression". >> >> I know from my earlier C-days that '42;' is a valid statement, and so >> the term "expression statement" makes sense to me. >> >> I know from various languages' syntax definitions that a number like >> '42' is a sensible form for an expression (and no operators required). >> It's also depending on the context. Where expressions may be written >> (and where not) depends on the concrete language; syntactically and >> also semantically. >> >> Usually I'd expect above "expression-statement" to serve some purpose, >> semantically. I don't recall that in "C" such an expression-statement >> would serve any purpose. (Or that they'd show any observable behavior, >> if that term fits the C-parlance better?) >> >> Or do these stand-alone values (the "expression-statement") have some >> practically useful semantics? >> >> In other languages such stand-alone values serve a purpose; e.g. they >> may determine the result value of a block that can then be used in an >> outer context; but in "C" such constructs are obviously not possible. >> >> What purpose serve such stand-alone numbers in places where statements >> are expected? > > I think it is just difficult for the syntax to ban certain expressons > and not others. How would you express that in the grammar? Well, I'd do that as it's done in other languages. Define _statements_ and define _expressions_. And defined expressions in contexts where a sensible operational semantics can be defined (as in mathematical formulas, actual function parameter lists, etc.), but not in places where statements are expected. > > If you ramp up the warnings, then you'll get messages like 'statement > with no effect' or 'computed value not used', since sometimes there are > side-effects that are needed: > > f() + g(); > > f() and g() both do something, but nothing is done with their sum. Right. And I wouldn't allow a mathematical formula where the results are calculated but not used, here an expression, as a statement. But your example may indeed lead to the actual answer to my question; when writing just f(); There's no distinction of procedures and functions in "C". One cannot tell whether that f() is a "procedure" (i.e. a function with no return value, or one with return value but the call just relying on the side effects). In "C" any value of f() just gets discarded in this context. That of course doesn't mean that it could be handled by the compilers and sensibly defined by the language, depending on how f() is actually defined. After all, 'f();' is not the same case as '42;'. But okay, we're talking about "C" here - so own design preferences are anyway irrelevant here. Janis > [...]
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-06-09 17:13 +0200 |
| Subject | Re: Expression statements (was Re: Meaning of "expression") |
| Message-ID | <1109ai6$1aa$1@dont-email.me> |
| In reply to | #399823 |
On 09/06/2026 16:30, Janis Papanagnou wrote:
> On 2026-06-09 15:53, Bart wrote:
>> On 09/06/2026 14:17, Janis Papanagnou wrote:
>>> On 2026-06-08 23:05, Keith Thompson wrote:
>>>> [...]
>>>> I've discussed this particular glitch before, but it's been a while.
>>>>
>>>> N3220 6.5.1 says:
>>>>
>>>> An *expression* is a sequence of operators and operands that
>>>> specifies computation of a value, or that designates an object
>>>> or a function, or that generates side effects, or that performs
>>>> a combination thereof.
>>>>
>>>> I believe the wording is unchanged from C90 up to the latest C202y
>>>> draft. Since the word "expression" is in italics, this is the
>>>> standard's definition of the word.
>>>>
>>>> This is a flawed definition. The terms "operator" and "operand"
>>>> are defined in 6.4.6:
>>>>
>>>> *punctuator: one of
>>>> [ ] ( )
>>>> [snip]
>>>> A punctuator is a symbol that has independent syntactic and
>>>> semantic
>>>> significance. Depending on context, it may specify an operation to
>>>> be performed (which in turn may yield a value or a function
>>>> designator, produce a side effect, or some combination thereof) in
>>>> which case it is known as an *operator* (other forms of
>>>> operator also
>>>> exist in some contexts). An *operand* is an entity on which an
>>>> operator acts.
>>>>
>>>> Consider this expression statement:
>>>>
>>>> 42;
>>>>
>>>> Is `42` an expression? Clearly it's intended to be, but there is no
>>>> operator, and therefore there is no operand, so it doesn't meet the
>>>> standard's definition of the word "expression".
>>>
>>> Above you used the term "expression statement", and then compare the
>>> "42" to an "expression".
>>>
>>> I know from my earlier C-days that '42;' is a valid statement, and so
>>> the term "expression statement" makes sense to me.
>>>
>>> I know from various languages' syntax definitions that a number like
>>> '42' is a sensible form for an expression (and no operators required).
>>> It's also depending on the context. Where expressions may be written
>>> (and where not) depends on the concrete language; syntactically and
>>> also semantically.
>>>
>>> Usually I'd expect above "expression-statement" to serve some purpose,
>>> semantically. I don't recall that in "C" such an expression-statement
>>> would serve any purpose. (Or that they'd show any observable behavior,
>>> if that term fits the C-parlance better?)
>>>
I don't see why you would expect that. Statements do not have to have
observable behaviour - indeed, I don't think any statements in C have
observable behaviour in themselves. A "statement" in C is basically
something that does not produce a value - "return", "if ...", "for...",
or it is an "expression statement". Expression statements are the most
common type of statement, I would guess (without having calculated
statistics.)
Expressions do not have to have observable behaviour. "x = y + z;" is a
perfectly good expression statement, but has no observable behaviour
(unless x, y or z are volatile). Most statements, and most expressions,
do not have observable behaviour. (Again, I have no statistics, but I
think this would be the solid majority of statements and expressions.)
Of course most statements and expressions /contribute/ to later
observable behaviour - such as printing out the result of a calculation.
Otherwise they are not much use (and compilers can eliminate or reduce
them, if the compiler is sure that there is no effect on observable
behaviour).
>>> Or do these stand-alone values (the "expression-statement") have some
>>> practically useful semantics?
>>>
>>> In other languages such stand-alone values serve a purpose; e.g. they
>>> may determine the result value of a block that can then be used in an
>>> outer context; but in "C" such constructs are obviously not possible.
>>>
>>> What purpose serve such stand-alone numbers in places where statements
>>> are expected?
>>
>> I think it is just difficult for the syntax to ban certain expressons
>> and not others. How would you express that in the grammar?
Agreed.
"42" is an expression of type "int", and so is 'printf("Hello\n")'. How
(and why) would a language distinguish between them and allow one but
not the other?
>
> Well, I'd do that as it's done in other languages.
>
> Define _statements_ and define _expressions_.
C defines statements and expressions. One type of statement is the
"expression statement", consisting of an expression followed by a
semi-colon. The expression is optional - if it is missing, you have a
null statement.
> And defined expressions
> in contexts where a sensible operational semantics can be defined (as
> in mathematical formulas, actual function parameter lists, etc.), but
> not in places where statements are expected.
>
So where would "printf" fit in this picture? A printf call gives a
result - it is an expression. It also has side-effects and observable
behaviour. "while (false) ;" is a valid statement, with no
side-effects. The distinction you want to make does not exist in C.
(And I don't think C is special in that regard.)
>>
>> If you ramp up the warnings, then you'll get messages like 'statement
>> with no effect' or 'computed value not used', since sometimes there
>> are side-effects that are needed:
>>
>> f() + g();
>>
>> f() and g() both do something, but nothing is done with their sum.
>
> Right. And I wouldn't allow a mathematical formula where the results
> are calculated but not used, here an expression, as a statement.
If the definitions of "f" and "g" are not visible to the compiler at the
time, how could the compiler know that they have no side-effects? Lots
of operators have side-effects - if you want to allow "x = y;" but
disallow "x + y;" you are going to have to have a lot of special cases
and extra grammar, syntax or constraint rules. It is better to do as C
does, and allow expression statements in the language and let compilers
and other tools help developers spot their mistakes.
>
> But your example may indeed lead to the actual answer to my question;
> when writing just
>
> f();
>
> There's no distinction of procedures and functions in "C". One cannot
> tell whether that f() is a "procedure" (i.e. a function with no return
> value, or one with return value but the call just relying on the side
> effects). In "C" any value of f() just gets discarded in this context.
>
Yes.
It is certainly possible for a language to distinguish between "pure
functions" and functions/procedures with side-effects. (C actually lets
you do that, with the [[reproducible]] and [[unsequenced]] attributes in
C23, or compiler extensions before C23.) These can aid compiler static
error checking and optimisation, but do not affect the grammar of the
language.
> That of course doesn't mean that it could be handled by the compilers
> and sensibly defined by the language, depending on how f() is actually
> defined. After all, 'f();' is not the same case as '42;'.
>
> But okay, we're talking about "C" here - so own design preferences are
> anyway irrelevant here.
>
> Janis
>
>> [...]
>
[toc] | [prev] | [next] | [standalone]
Page 8 of 18 — ← Prev page 1 … 6 7 [8] 9 10 … 18 Next page →
Back to top | Article view | comp.lang.c
csiph-web