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 317 — 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 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: 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") 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 6 of 16 — ← Prev page 1 … 4 5 [6] 7 8 … 16 Next page →
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-06-06 16:43 -0700 |
| Subject | Re: Constants and undefined behavior |
| Message-ID | <86mrx79qva.fsf@linuxsc.com> |
| In reply to | #399776 |
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: >> >>> I claim that an expression that looks like a constant expression >>> *isn't* a constant-expression if it doesn't appear in a context >>> that requires a constant-expression. >> >> Right. This question came up years ago in a Defect Report. The >> response from the Committee was basically the same as what you >> said: the 6.6 constraints for constant expressions apply only in >> situations where the C standard expressly requires a constant >> expression. (I don't have the DR in front of me; I'm summarizing >> based on memory, but am confident the actual wording is consistent >> with what I just said.) > > C99 DR 261 looks similar to what you're talking about. > > https://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_261.htm > > The Committee Response section says: > > In general, the interpretation of an expression for constantness > is context sensitive. For any expression which contains only > constants: > > - If the syntax or context only permits a constant expression, the > constraints of 6.6#3 and 6.6#4 shall apply. > - Otherwise, if the expression meets the requirements of 6.6 > (including any form accepted in accordance with 6.6#10), it is a > constant expression. > - Otherwise it is not a constant expression. > > That's close to what I claimed, but the second bullet point differs. > My claim was that, given: > > n = 2+2; > > 2+2 is not a constant expression because the grammar doesn't require > a constant expression in that context. The Committee's opinion > (at least at the time) was that it is a constant expression because > it meets the requirements of 6.6. > > But I *think* it's a distinction without a difference. [...] Right. The key point is that the constraints need to be satisfied only in situations where the C standard expressly requires a constant expression. Whether a given expression is called a "constant expression" doesn't matter; all that does matter is whether the constraints need to be satisfied.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-06-06 17:41 -0700 |
| Subject | Re: Constants and undefined behavior |
| Message-ID | <1102enu$26qtr$1@kst.eternal-september.org> |
| In reply to | #399777 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
[...]
>> That's close to what I claimed, but the second bullet point differs.
>> My claim was that, given:
>>
>> n = 2+2;
>>
>> 2+2 is not a constant expression because the grammar doesn't require
>> a constant expression in that context. The Committee's opinion
>> (at least at the time) was that it is a constant expression because
>> it meets the requirements of 6.6.
>>
>> But I *think* it's a distinction without a difference. [...]
>
> Right. The key point is that the constraints need to be satisfied
> only in situations where the C standard expressly requires a
> constant expression. Whether a given expression is called a
> "constant expression" doesn't matter; all that does matter is
> whether the constraints need to be satisfied.
Well, it matters a little bit, at least to me, even though the
distinction doesn't seem to affect the validity or semantics of
any C code.
A clear and unambiguous definition of what is or is not a "constant
expression" would make the language just a bit easier to understand
and explain. I'd even be satisified with the definition given in
the DR *if* it were clearly expressed in 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 | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-06-05 10:41 +0200 |
| Subject | Re: Constants and undefined behavior |
| Message-ID | <10vu236$fm4o$4@dont-email.me> |
| In reply to | #399725 |
On 2026-06-05 01:49, Dan Cross wrote: >> [...] > [...] > [ ... (INT_MAX+1)*0 ] > Furthermore, the expression above is obviously an integer > constant expression as defined by sec 6.6 para 8. Section 6.6, > para 4, reads in part, "Each constant expression shall evaluate > to a constant that is in the range of representable values for > its type." The expression, `(INT_MAX+1)*0` violates this > constraint, and so therefore a diagnostic is mandated as per > sec 5.1.1.3 para 1. That it appears in code that is not > obviously called from `main` doesn't change that. I'm curious about that "violation"; a violation would require (at least) two sorts of logical preconditions. - The first is that all *sequentially* (literally) evaluated sub-expression values are representable as value - INT_MAX+1 certainly can't be represented in generated code that conforms to the abstract *mathematical* value - but is that necessary if _the whole_ expression is (mathematically) just 0 (because of the final factor). And the second (related) is whether the order of the sub-expression evaluation is relevant; if we'd assume the expression evaluation to be considered from right to left then it would be irrelevant what's inside the parenthesis. From the standard quotes I cannot really recognize that these preconditions, how to determine UB/errors/violations, would be necessary. I'm no native speaker and I fear my question as formulated was hard to understand. It's basically the question of the standard implying (INT_MAX+1)*0 to be analyzed sequentially as written or whether it could as well analyze it from right to left and thus recognizing no problem, since from the mathematical view - but also practically - a concrete representable value of a here irrelevant sub-expression isn't necessary. Or another try of a (paraphrased) formulation; for the determination of constraint violations does the expression have strict (sort of) sequencing points _after each term_ (and each left-to-right sub-expression has to be well-defined) or can it be valued/analyzed as a whole not putting any preconditions about evaluation order etc. when determining the overall value? Janis PS: One yet non-considered question that was part of my original post was: "Is there any rationale from the _software designer_'s perspective?" > [...]
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-06-05 10:49 -0700 |
| Subject | Re: Constants and undefined behavior |
| Message-ID | <10vv27c$1aoa2$1@kst.eternal-september.org> |
| In reply to | #399741 |
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
> On 2026-06-05 01:49, Dan Cross wrote:
>>> [...]
>> [...]
>
>> [ ... (INT_MAX+1)*0 ]
>
>> Furthermore, the expression above is obviously an integer
>> constant expression as defined by sec 6.6 para 8. Section 6.6,
>> para 4, reads in part, "Each constant expression shall evaluate
>> to a constant that is in the range of representable values for
>> its type." The expression, `(INT_MAX+1)*0` violates this
>> constraint, and so therefore a diagnostic is mandated as per
>> sec 5.1.1.3 para 1. That it appears in code that is not
>> obviously called from `main` doesn't change that.
>
> I'm curious about that "violation"; a violation would require
> (at least) two sorts of logical preconditions. - The first is
> that all *sequentially* (literally) evaluated sub-expression
> values are representable as value - INT_MAX+1 certainly can't
> be represented in generated code that conforms to the abstract
> *mathematical* value - but is that necessary if _the whole_
> expression is (mathematically) just 0 (because of the final
> factor). And the second (related) is whether the order of the
> sub-expression evaluation is relevant; if we'd assume the
> expression evaluation to be considered from right to left then
> it would be irrelevant what's inside the parenthesis.
If the expression were evaluated right to left, it would still
compute INT_MAX+1, which is UB.
Let's look at an example where it's not in a context that requires a
constant expression:
int n;
n = (INT_MAX+1)*0;
In the abstract machine, the RHS is evaluated by adding INT_MAX
and 1 (which overflows, UB) and then multiplying the result by 0.
A compiler is allowed, but not required, to reduce the assignment to
`n = 0;`. If it does so, then no overflow occurs at run time --
but the definedness of the behavior is determined independent of
any optimizations. The C standard does not require any particular
behavior. It can set n to 0 because that's a valid consequence
of UB.
Let's take an example where it's definitely in a context that
requires an integer constant expression:
switch (0) {
case (INT_MAX+1)*0:
break;
}
The wording in 6.6 (Constant expressions) is slightly vague.
For example, I would assume that any subexpression of a constant
expression must be a constant expression, but it doesn't actually
say so.
But since, in the abstract machine, (INT_MAX+1)*0 doesn't yield
any defined value, I'd say it violates the constraint that "Each
constant expression shall evaluate to a constant that is in the
range of representable values for its type".
The alternative would be for to be a constant expression for
implementations that are able to recognize that anything multiplied
by zero is zero (analysis that compilers aren't required to perform),
and not for others.
On the other hand, "An implementation may accept other forms of
constant expressions; however, it is implementation-defined whether
they are an integer constant expression." That probably allows,
but does not reuqire, an implementation to treat (INT_MAX+1)*0 as
a constant expression with the value 0.
> From the standard quotes I cannot really recognize that these
> preconditions, how to determine UB/errors/violations, would be
> necessary.
>
> I'm no native speaker and I fear my question as formulated was
> hard to understand. It's basically the question of the standard
> implying (INT_MAX+1)*0 to be analyzed sequentially as written
> or whether it could as well analyze it from right to left and
> thus recognizing no problem, since from the mathematical view -
> but also practically - a concrete representable value of a here
> irrelevant sub-expression isn't necessary. Or another try of a
> (paraphrased) formulation; for the determination of constraint
> violations does the expression have strict (sort of) sequencing
> points _after each term_ (and each left-to-right sub-expression
> has to be well-defined) or can it be valued/analyzed as a whole
> not putting any preconditions about evaluation order etc. when
> determining the overall value?
>
> PS: One yet non-considered question that was part of my original
> post was: "Is there any rationale from the _software designer_'s
> perspective?"
From a programmer's perspective, it's good to have consistent
rules rather than leaving the decision of whether an expression
is a constant expression up to the undocumented vagaries of how
clever a compiler happens to be.
--
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-06 16:15 -0700 |
| Subject | Re: Constants and undefined behavior |
| Message-ID | <86qzmj9s7a.fsf@linuxsc.com> |
| In reply to | #399741 |
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
> PS: One yet non-considered question that was part of my original
> post was: "Is there any rationale from the _software designer_'s
> perspective?"
I didn't respond to your original question because it was based on a
misconception. Whether a given expression is a constant expression,
in the sense of needing to satisfy the constraints of 6.6, depends
not on the form of the expression but on the context in which it
appears. The 6.6 constraints apply only in situations where the C
standard expressly requires a constant expression. Other cases,
such as a use like this
int
whatever(){
int r = (int)(-1u/2) + 1;
return r;
}
do not need to satisfy the 6.6 constraints, because the C standard
doesn't require a constant expression in that context. (Note that
the initializing expression for 'r' does overflow the range of int
in implementations where UINT_MAX == INT_MAX*2.)
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-06-06 18:06 -0700 |
| Subject | Re: Constants and undefined behavior |
| Message-ID | <86ik7v9n1e.fsf@linuxsc.com> |
| In reply to | #399710 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> cross@spitfire.i.gajendra.net (Dan Cross) writes:
>
>> In article <865x3yd21n.fsf@linuxsc.com>,
>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>>
>>> cross@spitfire.i.gajendra.net (Dan Cross) writes:
>>>
>>>> In article <86ik81cfk5.fsf_-_@linuxsc.com>,
>>>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>
> [...]
>
>>>>> There's an important distinction to make here. Consider this
>>>>> program:
>>>>>
>>>>> #include <limits.h>
>>>>>
>>>>> int
>>>>> foo(){
>>>>> int zero = (INT_MAX+1)*0;
>>>>> return zero;
>>>>> }
>>>>>
>>>>> int
>>>>> main(){
>>>>> return 0;
>>>>> }
>>>>>
>>>>> This program does not transgress the bounds of undefined behavior.
>>>
>>> To clarify, the comments in my posting were meant to be read as
>>> saying the given text is the entire program, and that it is strictly
>>> conforming with respect to conforming hosted implementations.
>>> (Incidentally, given the rules for freestanding implementations, I'm
>>> not sure that it is even possible for any program to be strictly
>>> conforming with respect to conforming freestanding implementations.
>>> In any case my statements were meant only in the context of hosted
>>> implementations.)
[...]
> foo() has undefined behavior if it's called, so replacing its
> body with trapping code is valid.
Right.
> But (I'm reasonably sure that)
> an implementation cannot reject a program just because it can't
> prove that it has no undefined behavior during execution. [...]
Right.
>> In your example, `foo` clearly exhibits UB; I think your
>> argument is whether that has a realized effect or not, since the
>> UB is not invoked. I'm saying that in general a compiler cannot
>> possibly know that when it compiles `foo`, and is free to assume
>> the worst.
>
> foo() exhibits UB if and only if it's called during execution.
Right.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-06-07 22:34 -0700 |
| Subject | Re: Constants and undefined behavior |
| Message-ID | <867bo9a937.fsf@linuxsc.com> |
| In reply to | #399779 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: [...] >> But (I'm reasonably sure that) >> an implementation cannot reject a program just because it can't >> prove that it has no undefined behavior during execution. [...] > > Right. Expanding on that, there is no requirement even to try to prove such a conjecture. An implementation could simply give a warning like "there may be undiagnosed constraint violations in this compilation", and accept the TU no matter what (except of course for the dreaded #error preprocessing directive, which if encountered in a live portion of the translation must result in a rejection). I presume none of what I'm saying here is news to the usual suspects; mostly I'm saying it just to remind myself.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-06-08 23:05 -0700 |
| Subject | Re: Constants and undefined behavior |
| Message-ID | <86tsrc8d0b.fsf@linuxsc.com> |
| In reply to | #399693 |
cross@spitfire.i.gajendra.net (Dan Cross) writes:
> In article <865x3yd21n.fsf@linuxsc.com>,
> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>
>> cross@spitfire.i.gajendra.net (Dan Cross) writes:
>>
>>> In article <86ik81cfk5.fsf_-_@linuxsc.com>,
>>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>>>
>>>> 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? [...]
>>>>
>>>> There's an important distinction to make here. Consider this
>>>> program:
>>>>
>>>> #include <limits.h>
>>>>
>>>> int
>>>> foo(){
>>>> int zero = (INT_MAX+1)*0;
>>>> return zero;
>>>> }
>>>>
>>>> int
>>>> main(){
>>>> return 0;
>>>> }
>>>>
>>>> This program does not transgress the bounds of undefined behavior.
>>
>> To clarify, the comments in my posting were meant to be read as
>> saying the given text is the entire program, and that it is strictly
>> conforming with respect to conforming hosted implementations.
>> (Incidentally, given the rules for freestanding implementations, I'm
>> not sure that it is even possible for any program to be strictly
>> conforming with respect to conforming freestanding implementations.
>> In any case my statements were meant only in the context of hosted
>> implementations.)
>
> Ok.
>
>>> [snip]
>>> Perhaps you mean that this is irrelevant because `foo` is not
>>> invoked, but I see no reason why that need be the case in e.g.
>>> a freestanding environment.
>>
>> I explained the context of my previous statements above. Sorry for
>> not saying that in the original message.
>>
>>> In a hosted environment, I don't
>>> think anything explicitly prevents `foo` from being called after
>>> `main` returns (though I can't imagine that would happen in real
>>> life; it would be weird if it did).
>>
>> The semantics described in the ISO C standard don't admit that
>> possibility.
I have read through much of what has been said in the subthread
following this posting. I expect I will not be responding to much
of it; my overall sense is that the discussion is mostly confused.
I would like to say one thing here, and see if that helps things.
> Could you please point to where it says this, in the C standard?
>
> I cannot find anything that says that arbitrary code cannot run
> after `main()` returns, and I don't see how that could possibly
> be true.
The logic here is backwards. The C standard is prescriptive: it
says what _does_ happen, not what _doesn't_ happen. If one wants
to establish that some "action" takes place, it is necessary to
find a passage, or passages, in the C standard that, if all are
taken together, shows that the "action" occurs, or at least that it
can occur. The C standard doesn't need to say that, for example, a
function x() other than main(), whose name is never referenced,
will never be called. If someone wants to establish that x() could
be called, there needs to be a chain of reasoning going through the
semantic descriptions given in the C standard, to show that a call
to x() could occur. If there is no such chain of reasoning, naming
the pertinent passages in the C standard, to establish a possible
call, then there is no possible call. In other words the burden of
proof for a claim that some action could occur rests on whoever is
making the claim; there is no need to look for something in the C
standard that says something cannot occur.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-06-09 10:19 +0000 |
| Subject | Re: Constants and undefined behavior |
| Message-ID | <1108pb9$omm$1@reader1.panix.com> |
| In reply to | #399805 |
In article <86tsrc8d0b.fsf@linuxsc.com>,
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>cross@spitfire.i.gajendra.net (Dan Cross) writes:
>[snip]
>> I cannot find anything that says that arbitrary code cannot run
>> after `main()` returns, and I don't see how that could possibly
>> be true.
>
>The logic here is backwards. The C standard is prescriptive: it
>says what _does_ happen, not what _doesn't_ happen.
The definition of undefined behavior in the standard says that
it _imposes no requirements._ It is explicit that it says it
mandates neither "what _does_ happen" nor "what _doesn't_
happen."
>If one wants
>to establish that some "action" takes place, it is necessary to
>find a passage, or passages, in the C standard that, if all are
>taken together, shows that the "action" occurs, or at least that it
>can occur.
So you're saying that the proverbial nasal demons quip about UB
is incorrect, since it's not proscribed by the standard. Thanks
for clarfiying that.
>The C standard doesn't need to say that, for example, a
>function x() other than main(), whose name is never referenced,
>will never be called. If someone wants to establish that x() could
>be called, there needs to be a chain of reasoning going through the
>semantic descriptions given in the C standard, to show that a call
>to x() could occur.
Actually, no, a reference to a function is not necessary. A
couple of years ago, a well-publicized issue in a C++ compiler a
couple of years ago was something along the lines of this:
```
#include <stdio.h>
void foo(void);
int
main(void)
{
for (;;);
}
void
foo(void)
{
printf("never called\n");
}
```
The result of which, when run, was to print the text "never
called" and exit. That compiler was conformant with the text
of the standard.
>If there is no such chain of reasoning, naming
>the pertinent passages in the C standard, to establish a possible
>call, then there is no possible call. In other words the burden of
>proof for a claim that some action could occur rests on whoever is
>making the claim; there is no need to look for something in the C
>standard that says something cannot occur.
See above.
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-06-09 15:12 -0700 |
| Subject | Re: Constants and undefined behavior |
| Message-ID | <110a34q$b2kq$2@kst.eternal-september.org> |
| In reply to | #399815 |
cross@spitfire.i.gajendra.net (Dan Cross) writes:
[...]
> Actually, no, a reference to a function is not necessary. A
> couple of years ago, a well-publicized issue in a C++ compiler a
> couple of years ago was something along the lines of this:
>
> ```
> #include <stdio.h>
> void foo(void);
> int
> main(void)
> {
> for (;;);
> }
>
> void
> foo(void)
> {
> printf("never called\n");
> }
> ```
>
> The result of which, when run, was to print the text "never
> called" and exit. That compiler was conformant with the text
> of the standard.
[...]
That doesn't make sense to me. Do you have a citation to this incident,
and is it relevant to C?
There is a special rule in C about implementations being allowed
to assume that an infinite loop terminates (N3220 6.8.6.1p4),
but (a) it wouldn't apply to this case, and (b) even if it did,
it wouldn't imply that an implicit call to foo would be permitted.
I can imagine an argument that the program has undefined behavior
and therefore it could print "never called" or "nasal demons",
but I'd have to see the argument.
--
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-10 14:37 +0000 |
| Subject | Re: Constants and undefined behavior |
| Message-ID | <110bsqd$9ab$1@reader1.panix.com> |
| In reply to | #399831 |
In article <110a34q$b2kq$2@kst.eternal-september.org>,
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>cross@spitfire.i.gajendra.net (Dan Cross) writes:
>[...]
>> Actually, no, a reference to a function is not necessary. A
>> couple of years ago, a well-publicized issue in a C++ compiler a
>> couple of years ago was something along the lines of this:
>>
>> ```
>> #include <stdio.h>
>> void foo(void);
>> int
>> main(void)
>> {
>> for (;;);
>> }
>>
>> void
>> foo(void)
>> {
>> printf("never called\n");
>> }
>> ```
>>
>> The result of which, when run, was to print the text "never
>> called" and exit. That compiler was conformant with the text
>> of the standard.
>[...]
>
>That doesn't make sense to me. Do you have a citation to this incident,
Yes: https://godbolt.org/z/d1WP4KP99
There was such an outcry when this was discovered that the C++
standard was modified to add a note explicitly allowing,
"trivial infinite loops, which cannot be removed or reordered."
https://eel.is/c++draft/intro.progress
That change is commit 29fcc1c1fab7277d96bbd2ccd37b0c14dfd75a0e
(https://github.com/cplusplus/draft/commit/29fcc1c1fab7277d96bbd2ccd37b0c14dfd75a0e)
in response to P2809:
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p2809r3.html
>and is it relevant to C?
Here's a C version with the same behavior:
```
term% cat weird.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
clang version 22.1.6
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
term% clang -Wall -pedantic -O1 -std=c23 -o weird weird.c
term% ./weird
Hello, World!
term%
```
>There is a special rule in C about implementations being allowed
>to assume that an infinite loop terminates (N3220 6.8.6.1p4),
The program above meets the criteria in sec 6.8.6.1 para 4 that
allows an implementation to assume that the loop terminates.
Godbolt link: https://godbolt.org/z/q46o5cYGM
>but (a) it wouldn't apply to this case, and (b) even if it did,
>it wouldn't imply that an implicit call to foo would be permitted.
>I can imagine an argument that the program has undefined behavior
>and therefore it could print "never called" or "nasal demons",
>but I'd have to see the argument.
Regehr aluded to this with his taxonomy of undefined functions.
For a function that is always undefined (a "Type 3" function), a
compiler is under no obligation to even produce a return
instruction for it, and the behavior of a call to such a
function is totally undefined. Nothing stops it from cascading
into whatever the linker happens to put after it.
Therefore, given UB, it is not necessary to have a reference to
some function in a program's source text in order for it to be
executed.
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-06-10 18:30 +0000 |
| Subject | Re: Constants and undefined behavior |
| Message-ID | <110cagt$f7e$1@reader1.panix.com> |
| In reply to | #399864 |
In article <110bsqd$9ab$1@reader1.panix.com>,
Dan Cross <cross@spitfire.i.gajendra.net> wrote:
>In article <110a34q$b2kq$2@kst.eternal-september.org>,
>[snip]
>Here's a C version with the same behavior:
>
>```
>term% cat weird.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
>clang version 22.1.6
>Target: x86_64-pc-linux-gnu
>Thread model: posix
>InstalledDir: /usr/bin
>term% clang -Wall -pedantic -O1 -std=c23 -o weird weird.c
>term% ./weird
>Hello, World!
>term%
>```
Replying to myself here, but...this is another example of weird
behavior:
```
term% cat boo.c
#include <limits.h>
int
monstartup(void)
{
return INT_MAX + 1;
}
int
main(void)
{
return 0;
}
term% clang --version | sed 1q
FreeBSD clang version 19.1.7 (https://github.com/llvm/llvm-project.git llvmorg-19.1.7-0-gcd708029e0b2)
term% clang -Wall -Wextra -pedantic -pedantic-errors -pg -fsanitize=undefined -o boo boo.c
boo.c:6:17: warning: overflow in expression; result is -2'147'483'648 with type 'int' [-Winteger-overflow]
6 | return INT_MAX + 1;
| ~~~~~~~~^~~
1 warning generated.
term% ./boo
boo.c:6:17: runtime error: signed integer overflow: 2147483647 + 1 cannot be represented in type 'int'
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior boo.c:6:17
term%
```
(I admit that I am cheating a bit, but I claim that this program
is strictly conforming.)
- Dan C.
[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]
Page 6 of 16 — ← Prev page 1 … 4 5 [6] 7 8 … 16 Next page →
Back to top | Article view | comp.lang.c
csiph-web