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 448 — 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 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") 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 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 Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-15 17:31 -0700
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 9 of 23 — ← Prev page 1 … 7 8 [9] 10 11 … 23 Next page →
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2026-06-15 21:59 -0400 |
| Subject | Re: Constants and undefined behavior |
| Message-ID | <110qali$3q27m$1@dont-email.me> |
| In reply to | #400050 |
On 14/06/2026 16:33, Dan Cross wrote: ... > Here's the problem that I have with this line of reasoning. C > is a language that has considerable history; there was a large > body of C code written before the first standard was ever > created, in 1988; C was a teenager. And it took many years for > decent quality ANSI C compilers to be ubiquitous. C could > legally drink by then. > > "Undefined Behavior", in C, in the manner usually discussed in > this newsgroup, was introduced with the first standard. That > means that there is --- still --- a large body of software that > has "UB" that was put there before UB existed as a thing > programmers needed to worry about in C. "undefined behavior", defined as "behavior ... for which this international standard imposes no requirements" Was introduced by the first standard. However, before there was a standard there was K&R C, the closest thing they had to a standard. And though the phrase "undefined behavior" was not in use, there was "behavior for which K&R C imposes no requirements". In fact, there was a great deal more of it, since K&R C was not written as carefully and precisely as the first standard, so it left a great deal more behavior that was "undefined by omission of any relevant definition" than there was in the first standard.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-06-16 04:59 +0000 |
| Subject | Re: Constants and undefined behavior |
| Message-ID | <110ql7q$hb6$1@reader1.panix.com> |
| In reply to | #400075 |
In article <110qali$3q27m$1@dont-email.me>, James Kuyper <jameskuyper@alumni.caltech.edu> wrote: >On 14/06/2026 16:33, Dan Cross wrote: >... >> Here's the problem that I have with this line of reasoning. C >> is a language that has considerable history; there was a large >> body of C code written before the first standard was ever >> created, in 1988; C was a teenager. And it took many years for >> decent quality ANSI C compilers to be ubiquitous. C could >> legally drink by then. >> >> "Undefined Behavior", in C, in the manner usually discussed in >> this newsgroup, was introduced with the first standard. That >> means that there is --- still --- a large body of software that >> has "UB" that was put there before UB existed as a thing >> programmers needed to worry about in C. > >"undefined behavior", defined as "behavior ... for which this >international standard imposes no requirements" Was introduced by the >first standard. However, before there was a standard there was K&R C, >the closest thing they had to a standard. And though the phrase >"undefined behavior" was not in use, there was "behavior for which K&R C >imposes no requirements". In fact, there was a great deal more of it, >since K&R C was not written as carefully and precisely as the first >standard, so it left a great deal more behavior that was "undefined by >omission of any relevant definition" than there was in the first standard. I am guessing that there was supposed to be a point in there somewhere, but I can't find it. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-06-29 05:41 -0700 |
| Subject | Re: Constants and undefined behavior |
| Message-ID | <86mrwd7c49.fsf@linuxsc.com> |
| In reply to | #400050 |
cross@spitfire.i.gajendra.net (Dan Cross) writes: [...] > "Undefined Behavior", in C, in the manner usually discussed in > this newsgroup, was introduced with the first standard. The term but not the concept, which was there since the early days of C -- at least since K&R in 1978, and very likely earlier (I haven't reviewed any of the earlier descriptions of the language).
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-06-29 15:23 +0000 |
| Subject | Re: Constants and undefined behavior |
| Message-ID | <111u2lj$8q3$1@reader1.panix.com> |
| In reply to | #400284 |
In article <86mrwd7c49.fsf@linuxsc.com>, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >cross@spitfire.i.gajendra.net (Dan Cross) writes: > >[...] > >> "Undefined Behavior", in C, in the manner usually discussed in >> this newsgroup, was introduced with the first standard. > >The term but not the concept, which was there since the >early days of C -- at least since K&R in 1978, and very >likely earlier (I haven't reviewed any of the earlier >descriptions of the language). How much time elapsed before your response? If you cannot respond in a timely manner (read: within a week), then please do not respond at all. That said, not really. I've read K&R, both editions, and the first really doesn't define a concept that gives such supreme latitude to the compiler. They merely acknowledged that there existed things for which they could not give a good behavioral definition. The way that UB is defined and used in 2026 was absent in K&R in 1978. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-08-15 07:36 -0700 |
| Subject | Re: Constants and undefined behavior |
| Message-ID | <86bjb35u2z.fsf@linuxsc.com> |
| In reply to | #400286 |
cross@spitfire.i.gajendra.net (Dan Cross) writes: > In article <86mrwd7c49.fsf@linuxsc.com>, > Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > >> cross@spitfire.i.gajendra.net (Dan Cross) writes: >> >> [...] >> >>> "Undefined Behavior", in C, in the manner usually discussed in >>> this newsgroup, was introduced with the first standard. >> >> The term but not the concept, which was there since the >> early days of C -- at least since K&R in 1978, and very >> likely earlier (I haven't reviewed any of the earlier >> descriptions of the language). > > [...] not really. I've read K&R, both editions, and the > first really doesn't define a concept that gives such supreme > latitude to the compiler. [...] I didn't say any term was defined, only that such a concept is present in the writing.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-08-18 20:27 +0000 |
| Subject | Re: Constants and undefined behavior |
| Message-ID | <1162f8f$n2h$1@reader1.panix.com> |
| In reply to | #401209 |
In article <86bjb35u2z.fsf@linuxsc.com>, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >cross@spitfire.i.gajendra.net (Dan Cross) writes: >> In article <86mrwd7c49.fsf@linuxsc.com>, >> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >>> cross@spitfire.i.gajendra.net (Dan Cross) writes: >>> >>> [...] >>> >>>> "Undefined Behavior", in C, in the manner usually discussed in >>>> this newsgroup, was introduced with the first standard. >>> >>> The term but not the concept, which was there since the >>> early days of C -- at least since K&R in 1978, and very >>> likely earlier (I haven't reviewed any of the earlier >>> descriptions of the language). >> >> [...] not really. I've read K&R, both editions, and the >> first really doesn't define a concept that gives such supreme >> latitude to the compiler. [...] > >I didn't say any term was defined, only that such a >concept is present in the writing. How much time did you allow to lapse before responding to this thread? Please either respond promptly or not at all. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-06-11 13:29 -0700 |
| Subject | Re: Constants and undefined behavior |
| Message-ID | <110f5qm$1nfih$1@kst.eternal-september.org> |
| In reply to | #399884 |
David Brown <david.brown@hesbynett.no> writes:
[...]
> 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.
How about a loop that has a non-constant condition, but that is
not expected to terminate in normal usage?
while (! something_really_bad_happened()) {
sleep(1);
}
self_destruct();
A compiler could "assume" that the loop terminates, even if
something_really_bad never happens, and that assumption could result in
a call to self_destruct(). There are probably better ways to do that,
but it's straightforward code with seemingly obvious semantics that
an implementation is permitted to make unwarrated assumptions about.
[...]
--
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:08 +0000 |
| Subject | Re: Constants and undefined behavior |
| Message-ID | <110fpnd$8b6$1@reader1.panix.com> |
| In reply to | #399912 |
In article <110f5qm$1nfih$1@kst.eternal-september.org>,
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>David Brown <david.brown@hesbynett.no> writes:
>[...]
>> 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.
>
>How about a loop that has a non-constant condition, but that is
>not expected to terminate in normal usage?
>
> while (! something_really_bad_happened()) {
> sleep(1);
> }
> self_destruct();
>
>A compiler could "assume" that the loop terminates, even if
>something_really_bad never happens, and that assumption could result in
>a call to self_destruct(). There are probably better ways to do that,
>but it's straightforward code with seemingly obvious semantics that
>an implementation is permitted to make unwarrated assumptions about.
>
>[...]
I think, given the names, that this would _likely_ not meet the
criteria in 6.8.6 para 4. What would the criteria for,
`something_really_bad_happened` to return `true`? It would
almost certainly involve something that is listed as a require
for the compiler to prove could not happen in order to assume
the loop terminates; as written, the "assume it terminates"
pretty much only allows empty loop bodies, or bodies that just
do simple calculations. I guess it's possible, but I'm having a
hard time imagining that `something_really_bad_happened`
wouldn't do IO or access a volatile or do an atomic operation or
something.
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-06-12 11:02 +0200 |
| Subject | Re: Constants and undefined behavior |
| Message-ID | <110ghv0$21vi3$2@dont-email.me> |
| In reply to | #399912 |
On 11/06/2026 22:29, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
> [...]
>> 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.
>
> How about a loop that has a non-constant condition, but that is
> not expected to terminate in normal usage?
>
> while (! something_really_bad_happened()) {
> sleep(1);
> }
> self_destruct();
>
> A compiler could "assume" that the loop terminates, even if
> something_really_bad never happens, and that assumption could result in
> a call to self_destruct(). There are probably better ways to do that,
> but it's straightforward code with seemingly obvious semantics that
> an implementation is permitted to make unwarrated assumptions about.
>
The compiler can only assume that if it knows that the controlling
expression - the call to "something_really_bad_happened()" - does not
contain any IO operations, volatile accesses or atomic operations.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-06-11 17:45 +0200 |
| Subject | Re: Constants and undefined behavior |
| Message-ID | <110el6r$1nauc$7@dont-email.me> |
| In reply to | #399864 |
On 2026-06-10 16:37, Dan Cross wrote:
>> [...]
> 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%
> ```
Wow, that's really fascinating! (In a bad sense.)
And (in clang) just an effect of the '-O1' (as I notice).
I may have missed the "programming language design" wisdom of the
past decades. Back then we had the conception that "optimization"
is a method to transform a program to a _functionally equivalent_
code (one that is faster, requires less memory, or some such).
Janis
> [...]
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-06-10 15:11 -0700 |
| Subject | Re: Constants and undefined behavior |
| Message-ID | <86ldcm82ql.fsf@linuxsc.com> |
| In reply to | #399815 |
cross@spitfire.i.gajendra.net (Dan Cross) writes: > In article <86tsrc8d0b.fsf@linuxsc.com>, > Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >[...] >> 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: > [...] This is comp.lang.c. My comments were only about C, and not about C++. But of course you already knew that.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-06-10 22:44 +0000 |
| Subject | Re: Constants and undefined behavior |
| Message-ID | <110cpca$gl2$1@reader1.panix.com> |
| In reply to | #399872 |
In article <86ldcm82ql.fsf@linuxsc.com>,
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>cross@spitfire.i.gajendra.net (Dan Cross) writes:
>
>> In article <86tsrc8d0b.fsf@linuxsc.com>,
>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>>[...]
>>> 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:
>> [...]
>
>This is comp.lang.c. My comments were only about C, and not
>about C++. But of course you already knew that.
I see you did not read the other messages in the (sub)thread,
but ok, here it is again, in C:
```
term% cat what.c
#include <stdio.h>
int main(void) { for (unsigned int k = 0; k != 1; k += 2); return 0; }
void hello(void) { printf("Hello, World!\n"); }
term% clang --version | sed 1q
clang version 22.1.6
term% clang -Wall -pedantic -pedantic-errors -O1 -std=c23 -o what what.c
what.c:2:58: warning: for loop has empty body [-Wempty-body]
2 | int main(void) { for (unsigned int k = 0; k != 1; k += 2); return 0; }
| ^
what.c:2:58: note: put the semicolon on a separate line to silence this warning
1 warning generated.
term% ./what
Hello, World!
term%
```
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-06-10 16:19 -0700 |
| Subject | Re: Constants and undefined behavior |
| Message-ID | <110cre9$13aa9$1@kst.eternal-september.org> |
| In reply to | #399873 |
cross@spitfire.i.gajendra.net (Dan Cross) writes:
[...]
> I see you did not read the other messages in the (sub)thread,
> but ok, here it is again, in C:
>
> ```
> term% cat what.c
> #include <stdio.h>
> int main(void) { for (unsigned int k = 0; k != 1; k += 2); return 0; }
> void hello(void) { printf("Hello, World!\n"); }
> term% clang --version | sed 1q
> clang version 22.1.6
> term% clang -Wall -pedantic -pedantic-errors -O1 -std=c23 -o what what.c
> what.c:2:58: warning: for loop has empty body [-Wempty-body]
> 2 | int main(void) { for (unsigned int k = 0; k != 1; k += 2); return 0; }
> | ^
> what.c:2:58: note: put the semicolon on a separate line to silence this warning
> 1 warning generated.
> term% ./what
> Hello, World!
> term%
> ```
I see the same behavior.
The following largely repeats what I've written previously in
this thread.
Apparently the authors of clang decided that this statement in N3220
6.8.6.p4:
An iteration statement may be assumed by the implementation to
terminate if its controlling expression is not a constant
expression, ...
means that a program that violates that assumption has undefined
behavior. I intensely dislike both the rule and the way it's stated,
but I agree that the conclusion that the behavior is undefined is
a reasonable one.
Of course since the behavior is undefined, *anything* could happen.
I don't know what happened inside clang (or the minds of its
maintainers) that caused it to generate code that executes a
statement in the body of a function that's never called, but that's
just one of the infinitely many allowed behaviors. A quick look at the
generated code indicates that there's no x86-64 "retq" instruction
for either main() or hello(), and apparently control falls through
from the end of main() to the body of hello(). That seems weird.
It might just be a bug (but not one that, as far as I can tell,
violates the C standard).
A function whose body contains a construct that would have undefined
behavior if the function were called (not the case here) does not
cause undefined behavior if there are no calls to the function.
--
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-11 11:50 +0000 |
| Subject | Re: Constants and undefined behavior |
| Message-ID | <110e7dc$s4$1@reader1.panix.com> |
| In reply to | #399874 |
In article <110cre9$13aa9$1@kst.eternal-september.org>,
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>cross@spitfire.i.gajendra.net (Dan Cross) writes:
>[...]
>> I see you did not read the other messages in the (sub)thread,
>> but ok, here it is again, in C:
>>
>> ```
>> term% cat what.c
>> #include <stdio.h>
>> int main(void) { for (unsigned int k = 0; k != 1; k += 2); return 0; }
>> void hello(void) { printf("Hello, World!\n"); }
>> term% clang --version | sed 1q
>> clang version 22.1.6
>> term% clang -Wall -pedantic -pedantic-errors -O1 -std=c23 -o what what.c
>> what.c:2:58: warning: for loop has empty body [-Wempty-body]
>> 2 | int main(void) { for (unsigned int k = 0; k != 1; k += 2); return 0; }
>> | ^
>> what.c:2:58: note: put the semicolon on a separate line to silence this warning
>> 1 warning generated.
>> term% ./what
>> Hello, World!
>> term%
>> ```
>
>I see the same behavior.
>
>The following largely repeats what I've written previously in
>this thread.
>
>Apparently the authors of clang decided that this statement in N3220
>6.8.6.p4:
>
> An iteration statement may be assumed by the implementation to
> terminate if its controlling expression is not a constant
> expression, ...
>
>means that a program that violates that assumption has undefined
>behavior. I intensely dislike both the rule and the way it's stated,
>but I agree that the conclusion that the behavior is undefined is
>a reasonable one.
I think the behavior is technical "unspecified" in the sense of
the C standard, but yes, this is the important bit. The
controlling expresion is not constant, and the loop doesn't meet
any of the other criteria set forth in sec 6.8.6 para 4 for,
therefore, the translator may assume it terminates (it is
unspecified whether or not it does; either behavior is correct.
GCC, for example, appears not to make the same assumption).
>Of course since the behavior is undefined, *anything* could happen.
>I don't know what happened inside clang (or the minds of its
>maintainers) that caused it to generate code that executes a
>statement in the body of a function that's never called, but that's
>just one of the infinitely many allowed behaviors. A quick look at the
>generated code indicates that there's no x86-64 "retq" instruction
>for either main() or hello(), and apparently control falls through
>from the end of main() to the body of hello(). That seems weird.
Here's a slightly better version of `what.c` (that removes the
annoying "loop is body, move the semicolon to the next line"
warning):
```
#include <stdio.h>
int main(void) { unsigned int k = 0; while (k != 1) k += 2; return 0; }
void hello(void) { printf("Hello, World!\n"); }
```
I think the reasoning goes something like this: in optimization
phase $n$, the compiler determines that `k` can never be 1, and
thus the loop does not terminate, and therefore, `return 0;` is
inaccessible, so it's removed. Then, in phase $n + k$, for
$k>0$, it applies the rules of sec 6.8.6 para 4, assumes that
the loop must terminate, and therefore can be removed, and
removes it. The `return` is already gone. So what you're left
with is an label that just cascades into whatever is next in
object code; that just happens to be `hello`.
>It might just be a bug (but not one that, as far as I can tell,
>violates the C standard).
It's known. It was known when first reported a couple of years
ago in the C++ context, and I suspect they know about it now. I
can ask someone who works on LLVM. I suspect the reasoning will
be that this is important to guarantee forward progress, and
that they can't solve the halting problem, therefore such loops
can be removed. If that causes your program to do something
weird, then, well, don't do that.
>A function whose body contains a construct that would have undefined
>behavior if the function were called (not the case here) does not
>cause undefined behavior if there are no calls to the function.
True, but irrelevant to the point I was making, which is that UB
can induce a "call" to a function, even without a reference to
it appearing in the source text.
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-06-11 16:28 -0700 |
| Subject | Re: Constants and undefined behavior |
| Message-ID | <110fgbi$1qf9f$1@kst.eternal-september.org> |
| In reply to | #399896 |
cross@spitfire.i.gajendra.net (Dan Cross) writes:
> In article <110cre9$13aa9$1@kst.eternal-september.org>,
> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>cross@spitfire.i.gajendra.net (Dan Cross) writes:
>>[...]
>>> I see you did not read the other messages in the (sub)thread,
>>> but ok, here it is again, in C:
>>>
>>> ```
>>> term% cat what.c
>>> #include <stdio.h>
>>> int main(void) { for (unsigned int k = 0; k != 1; k += 2); return 0; }
>>> void hello(void) { printf("Hello, World!\n"); }
>>> term% clang --version | sed 1q
>>> clang version 22.1.6
>>> term% clang -Wall -pedantic -pedantic-errors -O1 -std=c23 -o what what.c
>>> what.c:2:58: warning: for loop has empty body [-Wempty-body]
>>> 2 | int main(void) { for (unsigned int k = 0; k != 1; k += 2); return 0; }
>>> | ^
>>> what.c:2:58: note: put the semicolon on a separate line to silence this warning
>>> 1 warning generated.
>>> term% ./what
>>> Hello, World!
>>> term%
>>> ```
>>
>>I see the same behavior.
>>
>>The following largely repeats what I've written previously in
>>this thread.
>>
>>Apparently the authors of clang decided that this statement in N3220
>>6.8.6.p4:
>>
>> An iteration statement may be assumed by the implementation to
>> terminate if its controlling expression is not a constant
>> expression, ...
>>
>>means that a program that violates that assumption has undefined
>>behavior. I intensely dislike both the rule and the way it's stated,
>>but I agree that the conclusion that the behavior is undefined is
>>a reasonable one.
>
> I think the behavior is technical "unspecified" in the sense of
> the C standard, but yes, this is the important bit. The
> controlling expresion is not constant, and the loop doesn't meet
> any of the other criteria set forth in sec 6.8.6 para 4 for,
> therefore, the translator may assume it terminates (it is
> unspecified whether or not it does; either behavior is correct.
> GCC, for example, appears not to make the same assumption).
Why do you think the behavior is unspecified rather that undefined?
Unspecified behavior is defined as: "behavior, that results from
the use of an unspecified value, or other behavior upon which
this document provides two or more possibilities and imposes
no further requirements on which is chosen in any instance".
(Implementation-defined behavior differs from unspecified behavior
in that the implementation must document how the choice is made.)
What are the "two more more possibilities" in this case?
[SNIP]
--
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-11 23:46 +0000 |
| Subject | Re: Constants and undefined behavior |
| Message-ID | <110fhc6$aem$1@reader1.panix.com> |
| In reply to | #399925 |
In article <110fgbi$1qf9f$1@kst.eternal-september.org>,
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>cross@spitfire.i.gajendra.net (Dan Cross) writes:
>> In article <110cre9$13aa9$1@kst.eternal-september.org>,
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>>cross@spitfire.i.gajendra.net (Dan Cross) writes:
>>>[...]
>>>> I see you did not read the other messages in the (sub)thread,
>>>> but ok, here it is again, in C:
>>>>
>>>> ```
>>>> term% cat what.c
>>>> #include <stdio.h>
>>>> int main(void) { for (unsigned int k = 0; k != 1; k += 2); return 0; }
>>>> void hello(void) { printf("Hello, World!\n"); }
>>>> term% clang --version | sed 1q
>>>> clang version 22.1.6
>>>> term% clang -Wall -pedantic -pedantic-errors -O1 -std=c23 -o what what.c
>>>> what.c:2:58: warning: for loop has empty body [-Wempty-body]
>>>> 2 | int main(void) { for (unsigned int k = 0; k != 1; k += 2); return 0; }
>>>> | ^
>>>> what.c:2:58: note: put the semicolon on a separate line to silence this warning
>>>> 1 warning generated.
>>>> term% ./what
>>>> Hello, World!
>>>> term%
>>>> ```
>>>
>>>I see the same behavior.
>>>
>>>The following largely repeats what I've written previously in
>>>this thread.
>>>
>>>Apparently the authors of clang decided that this statement in N3220
>>>6.8.6.p4:
>>>
>>> An iteration statement may be assumed by the implementation to
>>> terminate if its controlling expression is not a constant
>>> expression, ...
>>>
>>>means that a program that violates that assumption has undefined
>>>behavior. I intensely dislike both the rule and the way it's stated,
>>>but I agree that the conclusion that the behavior is undefined is
>>>a reasonable one.
>>
>> I think the behavior is technical "unspecified" in the sense of
>> the C standard, but yes, this is the important bit. The
>> controlling expresion is not constant, and the loop doesn't meet
>> any of the other criteria set forth in sec 6.8.6 para 4 for,
>> therefore, the translator may assume it terminates (it is
>> unspecified whether or not it does; either behavior is correct.
>> GCC, for example, appears not to make the same assumption).
>
>Why do you think the behavior is unspecified rather that undefined?
>
>Unspecified behavior is defined as: "behavior, that results from
>the use of an unspecified value, or other behavior upon which
>this document provides two or more possibilities and imposes
>no further requirements on which is chosen in any instance".
>(Implementation-defined behavior differs from unspecified behavior
>in that the implementation must document how the choice is made.)
>
>What are the "two more more possibilities" in this case?
The two choices are that the implementation may assume the loop
terminates, or it may not, but it doesn't say which. I don't
think that the language permits it to be UB. But I could be
wrong. It's a bit of a distinction without a difference as far
as the outcome is concerned.
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-06-11 18:29 -0700 |
| Subject | Re: Constants and undefined behavior |
| Message-ID | <110fnem$1s3nm$1@kst.eternal-september.org> |
| In reply to | #399926 |
cross@spitfire.i.gajendra.net (Dan Cross) writes:
> In article <110fgbi$1qf9f$1@kst.eternal-september.org>,
> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>cross@spitfire.i.gajendra.net (Dan Cross) writes:
>>> In article <110cre9$13aa9$1@kst.eternal-september.org>,
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>>>cross@spitfire.i.gajendra.net (Dan Cross) writes:
>>>>[...]
>>>>> I see you did not read the other messages in the (sub)thread,
>>>>> but ok, here it is again, in C:
>>>>>
>>>>> ```
>>>>> term% cat what.c
>>>>> #include <stdio.h>
>>>>> int main(void) { for (unsigned int k = 0; k != 1; k += 2); return 0; }
>>>>> void hello(void) { printf("Hello, World!\n"); }
>>>>> term% clang --version | sed 1q
>>>>> clang version 22.1.6
>>>>> term% clang -Wall -pedantic -pedantic-errors -O1 -std=c23 -o what what.c
>>>>> what.c:2:58: warning: for loop has empty body [-Wempty-body]
>>>>> 2 | int main(void) { for (unsigned int k = 0; k != 1; k += 2); return 0; }
>>>>> | ^
>>>>> what.c:2:58: note: put the semicolon on a separate line to silence this warning
>>>>> 1 warning generated.
>>>>> term% ./what
>>>>> Hello, World!
>>>>> term%
>>>>> ```
>>>>
>>>>I see the same behavior.
>>>>
>>>>The following largely repeats what I've written previously in
>>>>this thread.
>>>>
>>>>Apparently the authors of clang decided that this statement in N3220
>>>>6.8.6.p4:
>>>>
>>>> An iteration statement may be assumed by the implementation to
>>>> terminate if its controlling expression is not a constant
>>>> expression, ...
>>>>
>>>>means that a program that violates that assumption has undefined
>>>>behavior. I intensely dislike both the rule and the way it's stated,
>>>>but I agree that the conclusion that the behavior is undefined is
>>>>a reasonable one.
>>>
>>> I think the behavior is technical "unspecified" in the sense of
>>> the C standard, but yes, this is the important bit. The
>>> controlling expresion is not constant, and the loop doesn't meet
>>> any of the other criteria set forth in sec 6.8.6 para 4 for,
>>> therefore, the translator may assume it terminates (it is
>>> unspecified whether or not it does; either behavior is correct.
>>> GCC, for example, appears not to make the same assumption).
>>
>>Why do you think the behavior is unspecified rather that undefined?
>>
>>Unspecified behavior is defined as: "behavior, that results from
>>the use of an unspecified value, or other behavior upon which
>>this document provides two or more possibilities and imposes
>>no further requirements on which is chosen in any instance".
>>(Implementation-defined behavior differs from unspecified behavior
>>in that the implementation must document how the choice is made.)
>>
>>What are the "two more more possibilities" in this case?
>
> The two choices are that the implementation may assume the loop
> terminates, or it may not, but it doesn't say which. I don't
> think that the language permits it to be UB. But I could be
> wrong. It's a bit of a distinction without a difference as far
> as the outcome is concerned.
No, those are not the two choices. An assumption made by an
implementation is not behavior ("external appearance or action").
An implementation might invoke some behavior as a result of some
assumption.
If a loop doesn't terminate and the implementation assumes that
it does, the standard says nothing about the resulting behavior.
It doesn't provide two or more options for the actual behavior.
That's classic UB.
We've seen cases here where the actual behavior is falling through
into a function that's never called. That's certainly not a
possibility provided by the standard.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-06-12 01:54 +0000 |
| Subject | Re: Constants and undefined behavior |
| Message-ID | <110fos1$bfa$1@reader1.panix.com> |
| In reply to | #399933 |
In article <110fnem$1s3nm$1@kst.eternal-september.org>,
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>cross@spitfire.i.gajendra.net (Dan Cross) writes:
>> In article <110fgbi$1qf9f$1@kst.eternal-september.org>,
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>>cross@spitfire.i.gajendra.net (Dan Cross) writes:
>>>> In article <110cre9$13aa9$1@kst.eternal-september.org>,
>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>>>>cross@spitfire.i.gajendra.net (Dan Cross) writes:
>>>>>[...]
>>>>>> I see you did not read the other messages in the (sub)thread,
>>>>>> but ok, here it is again, in C:
>>>>>>
>>>>>> ```
>>>>>> term% cat what.c
>>>>>> #include <stdio.h>
>>>>>> int main(void) { for (unsigned int k = 0; k != 1; k += 2); return 0; }
>>>>>> void hello(void) { printf("Hello, World!\n"); }
>>>>>> term% clang --version | sed 1q
>>>>>> clang version 22.1.6
>>>>>> term% clang -Wall -pedantic -pedantic-errors -O1 -std=c23 -o what what.c
>>>>>> what.c:2:58: warning: for loop has empty body [-Wempty-body]
>>>>>> 2 | int main(void) { for (unsigned int k = 0; k != 1; k += 2); return 0; }
>>>>>> | ^
>>>>>> what.c:2:58: note: put the semicolon on a separate line to silence this warning
>>>>>> 1 warning generated.
>>>>>> term% ./what
>>>>>> Hello, World!
>>>>>> term%
>>>>>> ```
>>>>>
>>>>>I see the same behavior.
>>>>>
>>>>>The following largely repeats what I've written previously in
>>>>>this thread.
>>>>>
>>>>>Apparently the authors of clang decided that this statement in N3220
>>>>>6.8.6.p4:
>>>>>
>>>>> An iteration statement may be assumed by the implementation to
>>>>> terminate if its controlling expression is not a constant
>>>>> expression, ...
>>>>>
>>>>>means that a program that violates that assumption has undefined
>>>>>behavior. I intensely dislike both the rule and the way it's stated,
>>>>>but I agree that the conclusion that the behavior is undefined is
>>>>>a reasonable one.
>>>>
>>>> I think the behavior is technical "unspecified" in the sense of
>>>> the C standard, but yes, this is the important bit. The
>>>> controlling expresion is not constant, and the loop doesn't meet
>>>> any of the other criteria set forth in sec 6.8.6 para 4 for,
>>>> therefore, the translator may assume it terminates (it is
>>>> unspecified whether or not it does; either behavior is correct.
>>>> GCC, for example, appears not to make the same assumption).
>>>
>>>Why do you think the behavior is unspecified rather that undefined?
>>>
>>>Unspecified behavior is defined as: "behavior, that results from
>>>the use of an unspecified value, or other behavior upon which
>>>this document provides two or more possibilities and imposes
>>>no further requirements on which is chosen in any instance".
>>>(Implementation-defined behavior differs from unspecified behavior
>>>in that the implementation must document how the choice is made.)
>>>
>>>What are the "two more more possibilities" in this case?
>>
>> The two choices are that the implementation may assume the loop
>> terminates, or it may not, but it doesn't say which. I don't
>> think that the language permits it to be UB. But I could be
>> wrong. It's a bit of a distinction without a difference as far
>> as the outcome is concerned.
>
>No, those are not the two choices. An assumption made by an
>implementation is not behavior ("external appearance or action").
>An implementation might invoke some behavior as a result of some
>assumption.
>
>If a loop doesn't terminate and the implementation assumes that
>it does, the standard says nothing about the resulting behavior.
>It doesn't provide two or more options for the actual behavior.
>That's classic UB.
>
>We've seen cases here where the actual behavior is falling through
>into a function that's never called. That's certainly not a
>possibility provided by the standard.
Ok, fair point.
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-06-12 11:37 +0200 |
| Subject | Re: Constants and undefined behavior |
| Message-ID | <110gk13$21vi3$3@dont-email.me> |
| In reply to | #399926 |
On 12/06/2026 01:46, Dan Cross wrote:
> In article <110fgbi$1qf9f$1@kst.eternal-september.org>,
> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>> cross@spitfire.i.gajendra.net (Dan Cross) writes:
>>> In article <110cre9$13aa9$1@kst.eternal-september.org>,
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>>> cross@spitfire.i.gajendra.net (Dan Cross) writes:
>>>> [...]
>>>>> I see you did not read the other messages in the (sub)thread,
>>>>> but ok, here it is again, in C:
>>>>>
>>>>> ```
>>>>> term% cat what.c
>>>>> #include <stdio.h>
>>>>> int main(void) { for (unsigned int k = 0; k != 1; k += 2); return 0; }
>>>>> void hello(void) { printf("Hello, World!\n"); }
>>>>> term% clang --version | sed 1q
>>>>> clang version 22.1.6
>>>>> term% clang -Wall -pedantic -pedantic-errors -O1 -std=c23 -o what what.c
>>>>> what.c:2:58: warning: for loop has empty body [-Wempty-body]
>>>>> 2 | int main(void) { for (unsigned int k = 0; k != 1; k += 2); return 0; }
>>>>> | ^
>>>>> what.c:2:58: note: put the semicolon on a separate line to silence this warning
>>>>> 1 warning generated.
>>>>> term% ./what
>>>>> Hello, World!
>>>>> term%
>>>>> ```
>>>>
>>>> I see the same behavior.
>>>>
>>>> The following largely repeats what I've written previously in
>>>> this thread.
>>>>
>>>> Apparently the authors of clang decided that this statement in N3220
>>>> 6.8.6.p4:
>>>>
>>>> An iteration statement may be assumed by the implementation to
>>>> terminate if its controlling expression is not a constant
>>>> expression, ...
>>>>
>>>> means that a program that violates that assumption has undefined
>>>> behavior. I intensely dislike both the rule and the way it's stated,
>>>> but I agree that the conclusion that the behavior is undefined is
>>>> a reasonable one.
>>>
>>> I think the behavior is technical "unspecified" in the sense of
>>> the C standard, but yes, this is the important bit. The
>>> controlling expresion is not constant, and the loop doesn't meet
>>> any of the other criteria set forth in sec 6.8.6 para 4 for,
>>> therefore, the translator may assume it terminates (it is
>>> unspecified whether or not it does; either behavior is correct.
>>> GCC, for example, appears not to make the same assumption).
>>
>> Why do you think the behavior is unspecified rather that undefined?
>>
>> Unspecified behavior is defined as: "behavior, that results from
>> the use of an unspecified value, or other behavior upon which
>> this document provides two or more possibilities and imposes
>> no further requirements on which is chosen in any instance".
>> (Implementation-defined behavior differs from unspecified behavior
>> in that the implementation must document how the choice is made.)
>>
>> What are the "two more more possibilities" in this case?
>
> The two choices are that the implementation may assume the loop
> terminates, or it may not, but it doesn't say which. I don't
> think that the language permits it to be UB. But I could be
> wrong. It's a bit of a distinction without a difference as far
> as the outcome is concerned.
>
> - Dan C.
>
I think perhaps there is both undefined and unspecified aspects here.
The implementation may assume the loop terminates - that means, to me,
that there are no requirements for what happens if the loop does not
terminate. Not terminating would be UB.
However, I don't support clang's reasoning after that in this case. As
I see it, a compiler can reason that the loop terminates and then
executes "return 0;" because the non-terminating situation is UB and
cannot occur. Thus it can skip the loop and go straight to "return 0;".
Alternatively, it can reason that the non-terminating situation is UB
and we don't care what happens if it does not terminate - so "return 0;"
would be fine in that case too, simplifying the generated code.
But it seems that clang is reasoning that it can assume the loop
terminates, and it can prove that the loop does not terminate, and this
contradiction means that anything is allowed (including skipping all
code generation). The code has two conflicting semantics - it is an
infinite loop, and it is a terminating loop. I think the standards say
that the compiler /may/ consider the terminating loop interpretation as
correct, thus giving just "return 0;", or it may choose not to consider
that it terminates, and generate an infinite loop. Clang appears to
think that it can pick both options at once, which would give
contradictory behaviour, and therefore jump straight to UB.
I would say that the best behaviour for a compiler here would be to give
a warning, then it should pick one or the other defined behaviours.
(gcc picks the infinite loop, but does not give any warning.) I cannot
say for sure that clang's behaviour is incorrect - but it is certainly
very unhelpful and poor quality of implementation.
(I also think that it makes sense for compilers to use the "ud2" or
similar "undefined behaviour" trap instructions in cases where they know
an execution path is definitely UB and doing so does not affect the
efficiency of non-UB paths.)
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-08-15 07:58 -0700 |
| Subject | Re: Constants and undefined behavior |
| Message-ID | <8633wf5t30.fsf@linuxsc.com> |
| In reply to | #399873 |
cross@spitfire.i.gajendra.net (Dan Cross) writes:
> In article <86ldcm82ql.fsf@linuxsc.com>,
> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>
>> cross@spitfire.i.gajendra.net (Dan Cross) writes:
>>
>>> In article <86tsrc8d0b.fsf@linuxsc.com>,
>>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>>> [...]
>>>
>>>> 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:
>>> [...]
>>
>> This is comp.lang.c. My comments were only about C, and not
>> about C++. But of course you already knew that.
>
> I see you did not read the other messages in the (sub)thread,
> but ok, here it is again, in C:
>
> ```
> term% cat what.c
> #include <stdio.h>
> int main(void) { for (unsigned int k = 0; k != 1; k += 2); return 0; }
> void hello(void) { printf("Hello, World!\n"); }
> term% clang --version | sed 1q
> clang version 22.1.6
> term% clang -Wall -pedantic -pedantic-errors -O1 -std=c23 -o what what.c
> what.c:2:58: warning: for loop has empty body [-Wempty-body]
> 2 | int main(void) { for (unsigned int k = 0; k != 1; k += 2); return 0; }
> | ^
> what.c:2:58: note: put the semicolon on a separate line to silence [...]
> 1 warning generated.
> term% ./what
> Hello, World!
> term%
> ```
This is a childish argument.
[toc] | [prev] | [next] | [standalone]
Page 9 of 23 — ← Prev page 1 … 7 8 [9] 10 11 … 23 Next page →
Back to top | Article view | comp.lang.c
csiph-web