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 456 — 24 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 Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-13 14:57 +0200
Re: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-21 15:26 -0700
Re: Constants and undefined behavior antispam@fricas.org (Waldek Hebisch) - 2026-06-22 03:40 +0000
Re: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-15 07:50 -0700
Re: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-21 14:26 -0700
Re: Constants and undefined behavior antispam@fricas.org (Waldek Hebisch) - 2026-06-22 03:56 +0000
Re: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-29 06:27 -0700
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 David Brown <david.brown@hesbynett.no> - 2026-06-13 12:36 +0200
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-13 12:03 +0000
Re: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-14 12:35 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-13 12:02 +0000
Re: Constants and undefined behavior ram@zedat.fu-berlin.de (Stefan Ram) - 2026-06-13 12:13 +0000
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-13 12:44 +0000
Re: Constants and undefined behavior ram@zedat.fu-berlin.de (Stefan Ram) - 2026-06-14 17:22 +0000
Re: Constants and undefined behavior scott@slp53.sl.home (Scott Lurndal) - 2026-06-14 21:24 +0000
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-15 17:52 +0000
Re: Constants and undefined behavior David Brown <david.brown@hesbynett.no> - 2026-06-13 18:32 +0200
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-14 14:33 +0000
Re: Constants and undefined behavior David Brown <david.brown@hesbynett.no> - 2026-06-14 22:02 +0200
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-14 15:55 -0700
Re: Constants and undefined behavior David Brown <david.brown@hesbynett.no> - 2026-06-15 10:09 +0200
Re: Constants and undefined behavior antispam@fricas.org (Waldek Hebisch) - 2026-06-15 10:43 +0000
Re: Constants and undefined behavior David Brown <david.brown@hesbynett.no> - 2026-06-15 16:01 +0200
Re: Constants and undefined behavior antispam@fricas.org (Waldek Hebisch) - 2026-06-15 17:57 +0000
Re: Constants and undefined behavior David Brown <david.brown@hesbynett.no> - 2026-06-16 10:10 +0200
Re: Constants and undefined behavior Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-24 17:45 +0200
Re: Constants and undefined behavior "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-24 12:27 -0700
Re: Constants and undefined behavior Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-24 16:58 +0200
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-15 19:26 +0000
Re: Constants and undefined behavior James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-06-15 21:59 -0400
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-16 04:59 +0000
Re: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-29 05:41 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-29 15:23 +0000
Re: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-15 07:36 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-08-18 20:27 +0000
Re: Constants and undefined behavior Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-20 04:12 +0800
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: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-15 07:58 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-08-18 20:28 +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
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-15 09:37 -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-13 15:01 +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") Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-28 02:49 +0200
Re: Expression statements (was Re: Meaning of "expression") Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-27 21:00 -0700
Re: Expression statements (was Re: Meaning of "expression") Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-28 09:52 -0700
Re: Expression statements (was Re: Meaning of "expression") Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-28 18:28 -0700
Re: Expression statements (was Re: Meaning of "expression") Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-14 13:40 -0700
Re: Expression statements (was Re: Meaning of "expression") Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-14 14:13 -0700
Re: Expression statements (was Re: Meaning of "expression") Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-19 08:32 -0700
Re: Expression statements (was Re: Meaning of "expression") Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-19 15:09 -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") Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-28 03:16 +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: Meaning of "expression" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-15 00:42 -0700
The meaning of 42 ; (was: Re: Meaning of "expression") Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-15 19:42 +0800
Re: Meaning of "expression" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-15 05:36 -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-08-15 09:37 -0700
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-15 17:29 -0700
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-08-18 20:30 +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 Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-07-12 08:31 +0000
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 Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-07-12 08:32 +0000
Re: this girl calls c ugly "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-07-12 11:05 -0700
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: Microcontroller software stacks (was Re: this girl calls c ugly) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-21 14:13 -0700
Re: Microcontroller software stacks (was Re: this girl calls c ugly) David Brown <david.brown@hesbynett.no> - 2026-06-22 08:58 +0200
Re: Microcontroller software stacks (was Re: this girl calls c ugly) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-22 03:35 -0700
Re: Microcontroller software stacks (was Re: this girl calls c ugly) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-22 10:50 +0000
Re: Microcontroller software stacks (was Re: this girl calls c ugly) David Brown <david.brown@hesbynett.no> - 2026-06-22 12:59 +0200
Storage needed when there are bit-field members Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-28 09:42 -0700
Re: Storage needed when there are bit-field members Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-28 18:06 -0700
Re: Storage needed when there are bit-field members Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-28 20:20 -0700
Re: Storage needed when there are bit-field members Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-14 14:56 -0700
Re: Storage needed when there are bit-field members scott@slp53.sl.home (Scott Lurndal) - 2026-08-14 22:30 +0000
Re: Storage needed when there are bit-field members Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-15 16:10 -0700
Re: Storage needed when there are bit-field members scott@slp53.sl.home (Scott Lurndal) - 2026-08-16 15:20 +0000
Re: Storage needed when there are bit-field members antispam@fricas.org (Waldek Hebisch) - 2026-08-19 19:34 +0000
Re: Storage needed when there are bit-field members Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-19 15:26 -0700
Re: Storage needed when there are bit-field members David Brown <david.brown@hesbynett.no> - 2026-08-20 11:00 +0200
Re: Storage needed when there are bit-field members Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-14 14:19 -0700
Re: Microcontroller software stacks (was Re: this girl calls c ugly) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-22 10:45 +0000
Re: Microcontroller software stacks (was Re: this girl calls c ugly) scott@slp53.sl.home (Scott Lurndal) - 2026-06-22 15:23 +0000
Re: Microcontroller software stacks (was Re: this girl calls c ugly) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-14 13:23 -0700
Re: Microcontroller software stacks (was Re: this girl calls c ugly) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-08-18 20:32 +0000
Re: Microcontroller software stacks (was Re: this girl calls c ugly) scott@slp53.sl.home (Scott Lurndal) - 2026-06-22 15:04 +0000
Re: Microcontroller software stacks (was Re: this girl calls c ugly) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-22 13:02 -0700
Re: Microcontroller software stacks Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-14 12:51 -0700
Re: Microcontroller software stacks Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-15 05:02 +0800
Re: Microcontroller software stacks bart <bc@freeuk.com> - 2026-08-15 01:18 +0100
Re: Microcontroller software stacks Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-16 13:52 +0800
Re: Microcontroller software stacks Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-14 14:06 -0700
Re: Microcontroller software stacks scott@slp53.sl.home (Scott Lurndal) - 2026-08-14 21:42 +0000
Re: Microcontroller software stacks Michael S <already5chosen@yahoo.com> - 2026-08-15 22:13 +0300
Re: Microcontroller software stacks scott@slp53.sl.home (Scott Lurndal) - 2026-08-15 19:39 +0000
Re: Microcontroller software stacks Michael S <already5chosen@yahoo.com> - 2026-08-15 23:22 +0300
Re: Microcontroller software stacks scott@slp53.sl.home (Scott Lurndal) - 2026-08-16 14:38 +0000
Re: Microcontroller software stacks Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-16 16:11 -0700
Re: Microcontroller software stacks Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-15 16:16 -0700
Re: Microcontroller software stacks cross@spitfire.i.gajendra.net (Dan Cross) - 2026-08-18 20:34 +0000
Re: Microcontroller software stacks antispam@fricas.org (Waldek Hebisch) - 2026-08-19 19:57 +0000
Re: Microcontroller software stacks Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-15 17:31 -0700
Re: Microcontroller software stacks (was Re: this girl calls c ugly) Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-20 04:51 +0800
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 7 of 23 — ← Prev page 1 … 5 6 [7] 8 9 … 23 Next page →
| 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-10 14:55 -0700 |
| Subject | Re: Constants and undefined behavior |
| Message-ID | <110cmfk$116qm$3@kst.eternal-september.org> |
| In reply to | #399866 |
cross@spitfire.i.gajendra.net (Dan Cross) writes:
[...]
> 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;
> }
[SNIP]
> (I admit that I am cheating a bit, but I claim that this program
> is strictly conforming.)
I agree that the program is strictly conforming.
I don't know the details, but I think "monstartup" is a special name,
and that the program would behave as expected if a different name
were used. Since "monstartup" is not reserved, an implementation
that visibly treats it specially is not conforming.
--
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 23:32 +0000 |
| Subject | Re: Constants and undefined behavior |
| Message-ID | <110cs6v$3oj$1@reader1.panix.com> |
| In reply to | #399871 |
In article <110cmfk$116qm$3@kst.eternal-september.org>,
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>cross@spitfire.i.gajendra.net (Dan Cross) writes:
>[...]
>> 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;
>> }
>[SNIP]
>> (I admit that I am cheating a bit, but I claim that this program
>> is strictly conforming.)
>
>I agree that the program is strictly conforming.
>
>I don't know the details, but I think "monstartup" is a special name,
>and that the program would behave as expected if a different name
>were used. Since "monstartup" is not reserved, an implementation
>that visibly treats it specially is not conforming.
That's why it's cheating: `monstartup` is a function called from
the C runtime when using the `gprof` profiler, before `main` is
called, and I just happen to know that the csu code will call a
function by that name if compiled with profiling enabled. Thus,
this program can tickle the UB in `monstartup` in some weird
configurations. This is outside of the domain of strictly
defined C, but it is the sort of thing that happens in the real
world. Caveat emptor.
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-06-10 14:47 -0700 |
| Subject | Re: Constants and undefined behavior |
| Message-ID | <110cm0v$116qm$2@kst.eternal-september.org> |
| In reply to | #399864 |
cross@spitfire.i.gajendra.net (Dan Cross) writes:
> 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
So the reason the behavior was conforming was that the behavior of
the infinite loop is undefined. I dislike the way the C++ standard
expresses this. It says "The implementation *may assume* that any
thread will eventually do one of the following" (emphasis added).
More on that later in the context of the similar C rule.
>>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
Right. ("for (;;);" in the original program does not.)
Note that the C++ special rule applies only when the condition is
equivalent to a constant `true` and the body of the loop is empty.
An implementation can "assume" that any other loop will eventually
finish.
The rule in C is (6.8.6.1p4):
An iteration statement may be assumed by the implementation
to terminate if its controlling expression is not a constant
expression, and none of the following operations are performed
in its body, controlling expression or (in the case of a for
statement) its expression-3
— input/output operations
— accessing a volatile object
— synchronization or atomic operations.
`for (;;)` is treated as having a constant controlling expression.
This covers more cases than the C++ rule.
I dislike it for most of the same reasonss. It should be phrased
in terms of the permitted behavior of a program, not what an
implementation is allowed to "assume".
In addition to that, I dislike the whole idea. I think it's
intended to enable optimizations, but it means that for this
contrived program:
#include <stdio.h>
int main(void) {
bool keep_going = true;
while (keep_going) {
keep_going = true;
}
puts("never reached");
}
the implementation is allowed to "assume" that the loop eventually
terminates. It's not clear what permissions the implementation is being
given if the assumption is violated. I think the program could legally
print "never reached", but if violating the assumption implies undefined
behavior it could do anything.
A programmer could easily write a program similar to the above
and think that the meaning is perfectly clear, have it behave very
differently because of one obscure subclause in the standard.
>>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.
Of course. Given UB, anything can happen. There's nothing special
about a function that's never called in that context. It just
happens to be the way it showed up in the C++ incident.
--
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 | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-06-11 08:56 +0200 |
| Subject | Re: Constants and undefined behavior |
| Message-ID | <110dm6p$17r3s$1@dont-email.me> |
| In reply to | #399870 |
On 10/06/2026 23:47, Keith Thompson wrote:
> Right. ("for (;;);" in the original program does not.)
>
> Note that the C++ special rule applies only when the condition is
> equivalent to a constant `true` and the body of the loop is empty.
> An implementation can "assume" that any other loop will eventually
> finish.
>
> The rule in C is (6.8.6.1p4):
>
> An iteration statement may be assumed by the implementation
> to terminate if its controlling expression is not a constant
> expression, and none of the following operations are performed
> in its body, controlling expression or (in the case of a for
> statement) its expression-3
> — input/output operations
> — accessing a volatile object
> — synchronization or atomic operations.
>
> `for (;;)` is treated as having a constant controlling expression.
>
> This covers more cases than the C++ rule.
>
> I dislike it for most of the same reasonss. It should be phrased
> in terms of the permitted behavior of a program, not what an
> implementation is allowed to "assume".
>
> In addition to that, I dislike the whole idea. I think it's
> intended to enable optimizations, but it means that for this
> contrived program:
>
> #include <stdio.h>
> int main(void) {
> bool keep_going = true;
> while (keep_going) {
> keep_going = true;
> }
> puts("never reached");
> }
>
> the implementation is allowed to "assume" that the loop eventually
> terminates. It's not clear what permissions the implementation is being
> given if the assumption is violated. I think the program could legally
> print "never reached", but if violating the assumption implies undefined
> behavior it could do anything.
>
> A programmer could easily write a program similar to the above
> and think that the meaning is perfectly clear, have it behave very
> differently because of one obscure subclause in the standard.
The idea of all this is given in a footnote in the C standards - "This
is intended to allow compiler transformations such as removal of empty
loops even when termination cannot be proven."
The loop might originally have contained source code, but become empty
through pre-processing, or from other compiler transformations (such as
the compiler seeing that the "keep_going" variable is not volatile and
its value is never used, so assignments to it can be elided, or moving
other things outside the loop body).
A programmer /could/ write the "keep_going" loop you gave, and
mistakenly believe it to be infinite. But is it likely? In my
experience, infinite loops are generally very clearly written - either
as "for (;;)" loops or "while (true)" loops - or they are the result of
bugs in the code that accidentally run forever. If the loop is
accidentally infinite, the programmer will already be expecting it to
run the code after the loop.
Equally, I don't think it is likely that compilers will often be able to
use this rule to improve code generation - it would only help in a
situation where the loop's controlling expression is too complicated for
the compiler to be sure that it will terminate, but where the loop body
ends up effectively empty. I doubt if that turns up often in real code
either.
So while I agree that this kind of thing can lead to curiosities and
behaviour that seems counter-intuitive, and is popular with the "modern
compilers are evil" crowd, I really do not see it as an issue in
practice. There are many other mistakes programmers can make, or UB
that they hit accidentally - this is a drop in the ocean IMHO.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-06-11 11:38 +0000 |
| Subject | Re: Constants and undefined behavior |
| Message-ID | <110e6nr$pug$1@reader1.panix.com> |
| In reply to | #399884 |
In article <110dm6p$17r3s$1@dont-email.me>,
David Brown <david.brown@hesbynett.no> wrote:
>On 10/06/2026 23:47, Keith Thompson wrote:
>
>> Right. ("for (;;);" in the original program does not.)
>>
>> Note that the C++ special rule applies only when the condition is
>> equivalent to a constant `true` and the body of the loop is empty.
>> An implementation can "assume" that any other loop will eventually
>> finish.
>>
>> The rule in C is (6.8.6.1p4):
>>
>> An iteration statement may be assumed by the implementation
>> to terminate if its controlling expression is not a constant
>> expression, and none of the following operations are performed
>> in its body, controlling expression or (in the case of a for
>> statement) its expression-3
>> — input/output operations
>> — accessing a volatile object
>> — synchronization or atomic operations.
>>
>> `for (;;)` is treated as having a constant controlling expression.
>>
>> This covers more cases than the C++ rule.
>>
>> I dislike it for most of the same reasonss. It should be phrased
>> in terms of the permitted behavior of a program, not what an
>> implementation is allowed to "assume".
>>
>> In addition to that, I dislike the whole idea. I think it's
>> intended to enable optimizations, but it means that for this
>> contrived program:
>>
>> #include <stdio.h>
>> int main(void) {
>> bool keep_going = true;
>> while (keep_going) {
>> keep_going = true;
>> }
>> puts("never reached");
>> }
>>
>> the implementation is allowed to "assume" that the loop eventually
>> terminates. It's not clear what permissions the implementation is being
>> given if the assumption is violated. I think the program could legally
>> print "never reached", but if violating the assumption implies undefined
>> behavior it could do anything.
>>
>> A programmer could easily write a program similar to the above
>> and think that the meaning is perfectly clear, have it behave very
>> differently because of one obscure subclause in the standard.
>
>The idea of all this is given in a footnote in the C standards - "This
>is intended to allow compiler transformations such as removal of empty
>loops even when termination cannot be proven."
>
>The loop might originally have contained source code, but become empty
>through pre-processing, or from other compiler transformations (such as
>the compiler seeing that the "keep_going" variable is not volatile and
>its value is never used, so assignments to it can be elided, or moving
>other things outside the loop body).
I suspect the original intent is as you said, to support removal
of "dead" loops where the body has been optimized away, or
excised using conditional compilation. Something like,
#ifdef DEBUG
#define DOTHING true
#else
#define DOTHING false
#endif
...
for (int i = 0; i < n; i++) {
if (DOTHING) {
// Something complex here...
}
}
If `DEBUG` is not defined in the preprocessor, the compiler has
license to elide the entire loop as part of dead code
elimination.
>A programmer /could/ write the "keep_going" loop you gave, and
>mistakenly believe it to be infinite. But is it likely? In my
>experience, infinite loops are generally very clearly written - either
>as "for (;;)" loops or "while (true)" loops - or they are the result of
>bugs in the code that accidentally run forever. If the loop is
>accidentally infinite, the programmer will already be expecting it to
>run the code after the loop.
>
>Equally, I don't think it is likely that compilers will often be able to
>use this rule to improve code generation - it would only help in a
>situation where the loop's controlling expression is too complicated for
>the compiler to be sure that it will terminate, but where the loop body
>ends up effectively empty. I doubt if that turns up often in real code
>either.
>
>So while I agree that this kind of thing can lead to curiosities and
>behaviour that seems counter-intuitive, and is popular with the "modern
>compilers are evil" crowd, I really do not see it as an issue in
>practice. There are many other mistakes programmers can make, or UB
>that they hit accidentally - this is a drop in the ocean IMHO.
As I understand it, primarily by reading the C++ problem report,
which covers both C and C++ for background, the idea is to
guarantee forward progress for programs that make use of
threads: consider cooperatively-scheduled green threads; a
programmer who inadvertantly creates an infinite loop shouldn't
be able to starve all threads for access to the CPU.
Personally, I don't think C should be in the business of doing
such things. But it is what it is.
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-06-11 14:05 +0200 |
| Subject | Re: Constants and undefined behavior |
| Message-ID | <110e8a8$1dh8v$2@dont-email.me> |
| In reply to | #399894 |
On 11/06/2026 13:38, Dan Cross wrote:
> In article <110dm6p$17r3s$1@dont-email.me>,
> David Brown <david.brown@hesbynett.no> wrote:
>> On 10/06/2026 23:47, Keith Thompson wrote:
>>
>>> Right. ("for (;;);" in the original program does not.)
>>>
>>> Note that the C++ special rule applies only when the condition is
>>> equivalent to a constant `true` and the body of the loop is empty.
>>> An implementation can "assume" that any other loop will eventually
>>> finish.
>>>
>>> The rule in C is (6.8.6.1p4):
>>>
>>> An iteration statement may be assumed by the implementation
>>> to terminate if its controlling expression is not a constant
>>> expression, and none of the following operations are performed
>>> in its body, controlling expression or (in the case of a for
>>> statement) its expression-3
>>> — input/output operations
>>> — accessing a volatile object
>>> — synchronization or atomic operations.
>>>
>>> `for (;;)` is treated as having a constant controlling expression.
>>>
>>> This covers more cases than the C++ rule.
>>>
>>> I dislike it for most of the same reasonss. It should be phrased
>>> in terms of the permitted behavior of a program, not what an
>>> implementation is allowed to "assume".
>>>
>>> In addition to that, I dislike the whole idea. I think it's
>>> intended to enable optimizations, but it means that for this
>>> contrived program:
>>>
>>> #include <stdio.h>
>>> int main(void) {
>>> bool keep_going = true;
>>> while (keep_going) {
>>> keep_going = true;
>>> }
>>> puts("never reached");
>>> }
>>>
>>> the implementation is allowed to "assume" that the loop eventually
>>> terminates. It's not clear what permissions the implementation is being
>>> given if the assumption is violated. I think the program could legally
>>> print "never reached", but if violating the assumption implies undefined
>>> behavior it could do anything.
>>>
>>> A programmer could easily write a program similar to the above
>>> and think that the meaning is perfectly clear, have it behave very
>>> differently because of one obscure subclause in the standard.
>>
>> The idea of all this is given in a footnote in the C standards - "This
>> is intended to allow compiler transformations such as removal of empty
>> loops even when termination cannot be proven."
>>
>> The loop might originally have contained source code, but become empty
>> through pre-processing, or from other compiler transformations (such as
>> the compiler seeing that the "keep_going" variable is not volatile and
>> its value is never used, so assignments to it can be elided, or moving
>> other things outside the loop body).
>
> I suspect the original intent is as you said, to support removal
> of "dead" loops where the body has been optimized away, or
> excised using conditional compilation. Something like,
>
> #ifdef DEBUG
> #define DOTHING true
> #else
> #define DOTHING false
> #endif
>
> ...
> for (int i = 0; i < n; i++) {
> if (DOTHING) {
> // Something complex here...
> }
> }
>
> If `DEBUG` is not defined in the preprocessor, the compiler has
> license to elide the entire loop as part of dead code
> elimination.
>
I don't know about "original intent" - I was quoting a footnote in the C
standard, but I have not done any research like reading through the
rationale documents.
>> A programmer /could/ write the "keep_going" loop you gave, and
>> mistakenly believe it to be infinite. But is it likely? In my
>> experience, infinite loops are generally very clearly written - either
>> as "for (;;)" loops or "while (true)" loops - or they are the result of
>> bugs in the code that accidentally run forever. If the loop is
>> accidentally infinite, the programmer will already be expecting it to
>> run the code after the loop.
>>
>> Equally, I don't think it is likely that compilers will often be able to
>> use this rule to improve code generation - it would only help in a
>> situation where the loop's controlling expression is too complicated for
>> the compiler to be sure that it will terminate, but where the loop body
>> ends up effectively empty. I doubt if that turns up often in real code
>> either.
>>
>> So while I agree that this kind of thing can lead to curiosities and
>> behaviour that seems counter-intuitive, and is popular with the "modern
>> compilers are evil" crowd, I really do not see it as an issue in
>> practice. There are many other mistakes programmers can make, or UB
>> that they hit accidentally - this is a drop in the ocean IMHO.
>
> As I understand it, primarily by reading the C++ problem report,
> which covers both C and C++ for background, the idea is to
> guarantee forward progress for programs that make use of
> threads: consider cooperatively-scheduled green threads; a
> programmer who inadvertantly creates an infinite loop shouldn't
> be able to starve all threads for access to the CPU.
>
> Personally, I don't think C should be in the business of doing
> such things. But it is what it is.
>
> - Dan C.
>
I agree there. It is up to programmers to write useful programs - I
don't think it makes sense for a language standard to say that programs
have to either do something observable, or get out of the way and don't
block something else from being useful. But I have difficulty seeing
that this rule in the C standards would make much real-world difference
one way or the other.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-06-11 15:38 -0700 |
| Subject | Re: Constants and undefined behavior |
| Message-ID | <110fddl$1pooi$1@kst.eternal-september.org> |
| In reply to | #399894 |
cross@spitfire.i.gajendra.net (Dan Cross) writes:
[...]
> I suspect the original intent is as you said, to support removal
> of "dead" loops where the body has been optimized away, or
> excised using conditional compilation. Something like,
>
> #ifdef DEBUG
> #define DOTHING true
> #else
> #define DOTHING false
> #endif
>
> ...
> for (int i = 0; i < n; i++) {
> if (DOTHING) {
> // Something complex here...
> }
> }
>
> If `DEBUG` is not defined in the preprocessor, the compiler has
> license to elide the entire loop as part of dead code
> elimination.
I think I see what you mean, but in this particular case the loop
can be proven to terminate unless `i` is modified in the body of
the loop, and a compiler can elide the entire loop anyway.
[...]
> As I understand it, primarily by reading the C++ problem report,
> which covers both C and C++ for background, the idea is to
> guarantee forward progress for programs that make use of
> threads: consider cooperatively-scheduled green threads; a
> programmer who inadvertantly creates an infinite loop shouldn't
> be able to starve all threads for access to the CPU.
>
> Personally, I don't think C should be in the business of doing
> such things. But it is what it is.
I agree.
--
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 | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-06-11 23:07 +0000 |
| Subject | Re: Constants and undefined behavior |
| Message-ID | <ocHWR.151942$N9we.129907@fx16.iad> |
| In reply to | #399919 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>cross@spitfire.i.gajendra.net (Dan Cross) writes:
>[...]
>> I suspect the original intent is as you said, to support removal
>> of "dead" loops where the body has been optimized away, or
>> excised using conditional compilation. Something like,
>>
>> #ifdef DEBUG
>> #define DOTHING true
>> #else
>> #define DOTHING false
>> #endif
>>
>> ...
>> for (int i = 0; i < n; i++) {
>> if (DOTHING) {
>> // Something complex here...
>> }
>> }
>>
>> If `DEBUG` is not defined in the preprocessor, the compiler has
>> license to elide the entire loop as part of dead code
>> elimination.
>
>I think I see what you mean, but in this particular case the loop
>can be proven to terminate unless `i` is modified in the body of
...unless 'i' or 'n' is modified in the body of
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-06-11 17:43 -0700 |
| Subject | Re: Constants and undefined behavior |
| Message-ID | <110fko8$1qf9f$3@kst.eternal-september.org> |
| In reply to | #399923 |
scott@slp53.sl.home (Scott Lurndal) writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
[...]
>>I think I see what you mean, but in this particular case the loop
>>can be proven to terminate unless `i` is modified in the body of
>
> ...unless 'i' or 'n' is modified in the body of
Touché.
--
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 02:02 +0000 |
| Subject | Re: Constants and undefined behavior |
| Message-ID | <110fpcb$jo6$1@reader1.panix.com> |
| In reply to | #399919 |
In article <110fddl$1pooi$1@kst.eternal-september.org>,
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>cross@spitfire.i.gajendra.net (Dan Cross) writes:
>[...]
>> I suspect the original intent is as you said, to support removal
>> of "dead" loops where the body has been optimized away, or
>> excised using conditional compilation. Something like,
>>
>> #ifdef DEBUG
>> #define DOTHING true
>> #else
>> #define DOTHING false
>> #endif
>>
>> ...
>> for (int i = 0; i < n; i++) {
>> if (DOTHING) {
>> // Something complex here...
>> }
>> }
>>
>> If `DEBUG` is not defined in the preprocessor, the compiler has
>> license to elide the entire loop as part of dead code
>> elimination.
>
>I think I see what you mean, but in this particular case the loop
>can be proven to terminate unless `i` is modified in the body of
>the loop, and a compiler can elide the entire loop anyway.
Yes. Scott aluded to the rest; what if the actual body had set
the exit condition for the loop, and had been optimized away?
For example, given `DOTHING` as above:
for (int i = 0; i < n; ) {
if (DOTHING) {
// Something complex here...
i++;
}
}
Here, as before, the compiler is allowed to assume that the loop
_would_ terminate, and thus elide it, as before. Of course, it
is not forced to _guarantee_ that happens because it can't solve
the halting problem.
>[...]
>
>> As I understand it, primarily by reading the C++ problem report,
>> which covers both C and C++ for background, the idea is to
>> guarantee forward progress for programs that make use of
>> threads: consider cooperatively-scheduled green threads; a
>> programmer who inadvertantly creates an infinite loop shouldn't
>> be able to starve all threads for access to the CPU.
>>
>> Personally, I don't think C should be in the business of doing
>> such things. But it is what it is.
>
>I agree.
Yup.
It is one of the reasons C is no longer my favorite language.
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-06-11 17:34 +0200 |
| Subject | Re: Constants and undefined behavior |
| Message-ID | <110ekic$1naub$6@dont-email.me> |
| In reply to | #399884 |
On 2026-06-11 08:56, David Brown wrote:
> On 10/06/2026 23:47, Keith Thompson wrote:
>> [...]
>>
>> #include <stdio.h>
>> int main(void) {
>> bool keep_going = true;
>> while (keep_going) {
>> keep_going = true;
>> }
>> puts("never reached");
>> }
>>
>> [...]
>
> [...]
>
> The loop might originally have contained source code, but become empty
> through pre-processing, or from other compiler transformations (such as
> the compiler seeing that the "keep_going" variable is not volatile and
> its value is never used, so assignments to it can be elided, or moving
> other things outside the loop body).
>
> A programmer /could/ write the "keep_going" loop you gave, and
> mistakenly believe it to be infinite. But is it likely?
I think we should not make any assumptions about the "creativity" of a
programmer ("C" or else). - Semantics should be well defined, and then
clear to the programmer.
> In my
> experience, infinite loops are generally very clearly written - either
> as "for (;;)" loops or "while (true)" loops - or they are the result of
> bugs in the code that accidentally run forever. If the loop is
> accidentally infinite, the programmer will already be expecting it to
> run the code after the loop.
>
> [...]
>
> So while I agree that this kind of thing can lead to curiosities and
> behaviour that seems counter-intuitive, and is popular with the "modern
> compilers are evil" crowd, I really do not see it as an issue in
> practice. There are many other mistakes programmers can make, or UB
> that they hit accidentally - this is a drop in the ocean IMHO.
Languages shall be sensibly and clearly defined. For bad designs (or
bad standards) the language or standard should be blamed, and not the
critics badly and inappropriately despised as ''"modern compilers are
evil" crowd''. - Programmers are at the final end of the "food chain".
And there's a lot of horrible pits in the C-language where programmers
"made the mistake" to fall in; don't blame them, neither the ones who
silently suffer nor the ones who shout out.
Janis
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-06-12 10:58 +0200 |
| Subject | Re: Constants and undefined behavior |
| Message-ID | <110ghmv$21vi3$1@dont-email.me> |
| In reply to | #399902 |
On 11/06/2026 17:34, Janis Papanagnou wrote:
> On 2026-06-11 08:56, David Brown wrote:
>> On 10/06/2026 23:47, Keith Thompson wrote:
>>> [...]
>>>
>>> #include <stdio.h>
>>> int main(void) {
>>> bool keep_going = true;
>>> while (keep_going) {
>>> keep_going = true;
>>> }
>>> puts("never reached");
>>> }
>>>
>>> [...]
>>
>> [...]
>>
>> The loop might originally have contained source code, but become empty
>> through pre-processing, or from other compiler transformations (such
>> as the compiler seeing that the "keep_going" variable is not volatile
>> and its value is never used, so assignments to it can be elided, or
>> moving other things outside the loop body).
>>
>> A programmer /could/ write the "keep_going" loop you gave, and
>> mistakenly believe it to be infinite. But is it likely?
>
> I think we should not make any assumptions about the "creativity" of a
> programmer ("C" or else). - Semantics should be well defined, and then
> clear to the programmer.
I think the semantics of this "loops can be assumed to terminate" are
clearly defined in the standard. I agree that the details might not be
known to all C programmers, but I think they are only relevant in a very
small number of cases.
>
>> In my experience, infinite loops are generally very clearly written -
>> either as "for (;;)" loops or "while (true)" loops - or they are the
>> result of bugs in the code that accidentally run forever. If the loop
>> is accidentally infinite, the programmer will already be expecting it
>> to run the code after the loop.
>>
>> [...]
>>
>> So while I agree that this kind of thing can lead to curiosities and
>> behaviour that seems counter-intuitive, and is popular with the
>> "modern compilers are evil" crowd, I really do not see it as an issue
>> in practice. There are many other mistakes programmers can make, or
>> UB that they hit accidentally - this is a drop in the ocean IMHO.
>
> Languages shall be sensibly and clearly defined. For bad designs (or
> bad standards) the language or standard should be blamed, and not the
> critics badly and inappropriately despised as ''"modern compilers are
> evil" crowd''. - Programmers are at the final end of the "food chain".
> And there's a lot of horrible pits in the C-language where programmers
> "made the mistake" to fall in; don't blame them, neither the ones who
> silently suffer nor the ones who shout out.
>
I agree that standards should be clear, and standards documents should
be held accountable if they are not. There's no doubt that the C
standards are not perfect (Keith's "42 is not an expression" is an
example of that).
But it is less obvious that the language should be blamed for bad
design. As a wise man here said, "C is what it is". The reasons for
design decisions might be lost to history, inappropriate for a modern
language, or forced for compatibility reasons - but the language stands
with the rules it has. I don't know of anyone who uses a mainstream
programming language for serious work and does not think at least some
of its design decisions are bad - "bad" is highly subjective, depending
on both the programmer and the type of work they do. Just like for any
programming language, if you are programming in C, then you need to be
aware of the pitfalls of C or steer well clear of where pitfalls might be.
Ultimately, programming languages are subject to the equivalent of
market forces - the choice of language to use for a particular task is a
matter of weighing up what you think are the good and bad points for
available alternatives. As the incumbent in many situations, C of
course has an unfair advantage - but with enough incentive, people move
to other languages with their own benefits, disadvantages, and "bad"
design decisions. This is a slow process, but it is the only way forward.
As for my '"modern compilers are evil" crowd' comment, there are people
(not anyone involved in this discussion) who really do fall into that
camp. I've seen people who are experienced and respected developers
make all sorts of accusations to compiler developers, claiming they are
only interested in high scores on synthetic benchmarks and directly
insulting their motivations and integrity, blaming them for "breaking"
their code that relied on the effects of some kinds of UB. It is always
frustrating when you have code that works fine with one compiler
version, but using another compiler results in failure due to UB in your
code - especially if writing correct code gives inefficient results with
the first compiler. And it's fine to say you'd be happier if a
particular thing that is UB in C were not UB - but it is unreasonable to
blame compiler developers for implementing the language as it is defined.
I am not in any way saying that critics of aspects of C (the language,
the standards, or compiler implementations) should be dismissed or
despised - merely that the example of loop elimination leading to UB and
unexpected results is regularly used as "evidence" by those that hold
extreme positions about C, despite it being very unrealistic for the
issue to cause problems in real coding practice.
It is always best if compilers are able to warn you about problems in
your code - such as UB - and avoid surprising results. But I don't
think it is practical to expect them to catch everything, and too many
warnings will flood you with false positives. (gcc used to have a
warning for when code was elided - as the compiler got stronger and
gained more optimisations, the warning was dropped because eliding code
happened far too often to warn about.)
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-06-12 12:27 -0700 |
| Subject | Re: Constants and undefined behavior |
| Message-ID | <110hmi7$2e85g$1@kst.eternal-september.org> |
| In reply to | #399960 |
David Brown <david.brown@hesbynett.no> writes:
> On 11/06/2026 17:34, Janis Papanagnou wrote:
>> On 2026-06-11 08:56, David Brown wrote:
>>> On 10/06/2026 23:47, Keith Thompson wrote:
>>>> [...]
>>>>
>>>> #include <stdio.h>
>>>> int main(void) {
>>>> bool keep_going = true;
>>>> while (keep_going) {
>>>> keep_going = true;
>>>> }
>>>> puts("never reached");
>>>> }
>>>>
>>>> [...]
>>>
>>> [...]
>>>
>>> The loop might originally have contained source code, but become
>>> empty through pre-processing, or from other compiler
>>> transformations (such as the compiler seeing that the "keep_going"
>>> variable is not volatile and its value is never used, so
>>> assignments to it can be elided, or moving other things outside the
>>> loop body).
>>>
>>> A programmer /could/ write the "keep_going" loop you gave, and
>>> mistakenly believe it to be infinite. But is it likely?
>>
>> I think we should not make any assumptions about the "creativity" of
>> a programmer ("C" or else). - Semantics should be well defined, and
>> then clear to the programmer.
>
> I think the semantics of this "loops can be assumed to terminate" are
> clearly defined in the standard. I agree that the details might not
> be known to all C programmers, but I think they are only relevant in a
> very small number of cases.
I disagree that the semantics are clearly defined. N3220 6.8.6.1p4
is specified in terms of what an implementation may "assume", not in
terms of the semantics of the program. One can conclude that this
means that the program has undefined behavior if the assumption is
violated, but that's not directly stated. I don't know how many C
programmers know the standard well enough to reach that conclusion.
I'm not even 100% sure it's accurate.
The permission was added in C11 with little fanfare. It's not
mentioned in the list of major changes in the C11 Foreword.
The cases where it applies may be rarer than I had assumed, but
it at least has the potential to break existing code that was well
defined in C99.
The rationale is to provide more opportunities for optimization,
but it's not at all clear (at least to me) that it's particularly
successful. If cases where it can cause problems are rare, then
presumably cases where it's actually useful are rare. (That may
be an oversimplification.)
--
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 | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-06-13 12:36 +0200 |
| Subject | Re: Constants and undefined behavior |
| Message-ID | <110jbqv$2rgcj$1@dont-email.me> |
| In reply to | #400004 |
On 12/06/2026 21:27, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 11/06/2026 17:34, Janis Papanagnou wrote:
>>> On 2026-06-11 08:56, David Brown wrote:
>>>> On 10/06/2026 23:47, Keith Thompson wrote:
>>>>> [...]
>>>>>
>>>>> #include <stdio.h>
>>>>> int main(void) {
>>>>> bool keep_going = true;
>>>>> while (keep_going) {
>>>>> keep_going = true;
>>>>> }
>>>>> puts("never reached");
>>>>> }
>>>>>
>>>>> [...]
>>>>
>>>> [...]
>>>>
>>>> The loop might originally have contained source code, but become
>>>> empty through pre-processing, or from other compiler
>>>> transformations (such as the compiler seeing that the "keep_going"
>>>> variable is not volatile and its value is never used, so
>>>> assignments to it can be elided, or moving other things outside the
>>>> loop body).
>>>>
>>>> A programmer /could/ write the "keep_going" loop you gave, and
>>>> mistakenly believe it to be infinite. But is it likely?
>>>
>>> I think we should not make any assumptions about the "creativity" of
>>> a programmer ("C" or else). - Semantics should be well defined, and
>>> then clear to the programmer.
>>
>> I think the semantics of this "loops can be assumed to terminate" are
>> clearly defined in the standard. I agree that the details might not
>> be known to all C programmers, but I think they are only relevant in a
>> very small number of cases.
>
> I disagree that the semantics are clearly defined. N3220 6.8.6.1p4
> is specified in terms of what an implementation may "assume", not in
> terms of the semantics of the program. One can conclude that this
> means that the program has undefined behavior if the assumption is
> violated, but that's not directly stated. I don't know how many C
> programmers know the standard well enough to reach that conclusion.
> I'm not even 100% sure it's accurate.
>
> The permission was added in C11 with little fanfare. It's not
> mentioned in the list of major changes in the C11 Foreword.
> The cases where it applies may be rarer than I had assumed, but
> it at least has the potential to break existing code that was well
> defined in C99.
>
> The rationale is to provide more opportunities for optimization,
> but it's not at all clear (at least to me) that it's particularly
> successful. If cases where it can cause problems are rare, then
> presumably cases where it's actually useful are rare. (That may
> be an oversimplification.)
>
I agree on that last point. I doubt if any code would suffer if the
paragraph were removed entirely from the standard. And while I also
don't think much real-world code is at risk of problems from its
inclusion in the standard, as long as there is some risk of problems
with existing correct code, or some risk of confusion or
misunderstanding on the part of programmers reading the standard, then
it would be better if that paragraph had not been added to the standard
at all.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-06-13 12:03 +0000 |
| Subject | Re: Constants and undefined behavior |
| Message-ID | <110jgv3$cen$1@reader1.panix.com> |
| In reply to | #400004 |
In article <110hmi7$2e85g$1@kst.eternal-september.org>,
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>David Brown <david.brown@hesbynett.no> writes:
>> On 11/06/2026 17:34, Janis Papanagnou wrote:
>>> On 2026-06-11 08:56, David Brown wrote:
>>>> On 10/06/2026 23:47, Keith Thompson wrote:
>>>>> [...]
>>>>>
>>>>> #include <stdio.h>
>>>>> int main(void) {
>>>>> bool keep_going = true;
>>>>> while (keep_going) {
>>>>> keep_going = true;
>>>>> }
>>>>> puts("never reached");
>>>>> }
>>>>>
>>>>> [...]
>>>>
>>>> [...]
>>>>
>>>> The loop might originally have contained source code, but become
>>>> empty through pre-processing, or from other compiler
>>>> transformations (such as the compiler seeing that the "keep_going"
>>>> variable is not volatile and its value is never used, so
>>>> assignments to it can be elided, or moving other things outside the
>>>> loop body).
>>>>
>>>> A programmer /could/ write the "keep_going" loop you gave, and
>>>> mistakenly believe it to be infinite. But is it likely?
>>>
>>> I think we should not make any assumptions about the "creativity" of
>>> a programmer ("C" or else). - Semantics should be well defined, and
>>> then clear to the programmer.
>>
>> I think the semantics of this "loops can be assumed to terminate" are
>> clearly defined in the standard. I agree that the details might not
>> be known to all C programmers, but I think they are only relevant in a
>> very small number of cases.
>
>I disagree that the semantics are clearly defined. N3220 6.8.6.1p4
>is specified in terms of what an implementation may "assume", not in
>terms of the semantics of the program. One can conclude that this
>means that the program has undefined behavior if the assumption is
>violated, but that's not directly stated. I don't know how many C
>programmers know the standard well enough to reach that conclusion.
>I'm not even 100% sure it's accurate.
>
>The permission was added in C11 with little fanfare. It's not
>mentioned in the list of major changes in the C11 Foreword.
>The cases where it applies may be rarer than I had assumed, but
>it at least has the potential to break existing code that was well
>defined in C99.
Another example of something that was previously well-defined
and is now UB, I guess. :-/
>The rationale is to provide more opportunities for optimization,
>but it's not at all clear (at least to me) that it's particularly
>successful. If cases where it can cause problems are rare, then
>presumably cases where it's actually useful are rare. (That may
>be an oversimplification.)
I'm not sure that's the rationale: rather, it's to guarantee
forward progress. Again, that's not really the language's
purview.
- Dan C.
[toc] | [prev] | [next] | [standalone]
Page 7 of 23 — ← Prev page 1 … 5 6 [7] 8 9 … 23 Next page →
Back to top | Article view | comp.lang.c
csiph-web