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 455 — 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 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 6 of 23 — ← Prev page 1 … 4 5 [6] 7 8 … 23 Next page →
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-06-11 18:08 +0200 |
| Subject | Re: Constants and undefined behavior |
| Message-ID | <110emi7$1naub$7@dont-email.me> |
| In reply to | #399901 |
On 2026-06-11 17:20, Dan Cross wrote: > In article <110eht5$1naub$5@dont-email.me>, > Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote: >>> >>> I think biggest trouble is normal programmers. They already >>> struggle with current standard text. More formal presentation >>> could alienate even folks who now are able to explain standard >>> rules to other programmers. >> >> I'm not sure what "normal programmers" are. From own experience >> I can just say that there's a difference between what's "formal" >> in a "lawyer's speeches and texts" sense and what's formal in a >> mathematical sense. - The C-Standard as had been quoted here is >> more of a lawyer's text, with its inherent property of not being >> formally (in a mathematical sense) accurate (despite their tries; >> in both areas, law and programming language, respectively). It's >> thus not necessarily a problem if we'd have a more [mathematical] >> formal standard. - Programmers, as I see it, need definite texts. >> And rejection of the "lawyer's" sort of texts is not surprising. >> That not necessarily affects their acceptance will of more formal >> specifications. > > One hopes that a formal specification (that's a term of art, and > implies something that's mathematically precise) would be > accompanied by a commentary for more casual reading. Commentaries generally make sense, and they are one possibility to serve the needs also of programmers. But a more formal text would also help the authors of textbooks to provide a clearer description for those programmers that are repelled by standards papers. > However, > the truly precise, formal specification would be considered > definitive. Yes. (That's what I intended to express.) > > I think the odds of this ever happening for C are slim to none, > but it would be useful. I agree. (And I don't wait for that; I'm taking "C" as it is.) Janis
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2026-06-11 16:30 +0000 |
| Subject | Re: Constants and undefined behavior |
| Message-ID | <110enrj$15fs1$1@paganini.bofh.team> |
| In reply to | #399900 |
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
> On 2026-06-09 03:25, Waldek Hebisch wrote:
>> [...]
>
> Interesting views. - Thanks.
>
>>
>> I think biggest trouble is normal programmers. They already
>> struggle with current standard text. More formal presentation
>> could alienate even folks who now are able to explain standard
>> rules to other programmers.
>
> I'm not sure what "normal programmers" are. From own experience
> I can just say that there's a difference between what's "formal"
> in a "lawyer's speeches and texts" sense and what's formal in a
> mathematical sense. - The C-Standard as had been quoted here is
> more of a lawyer's text, with its inherent property of not being
> formally (in a mathematical sense) accurate (despite their tries;
> in both areas, law and programming language, respectively). It's
> thus not necessarily a problem if we'd have a more [mathematical]
> formal standard. - Programmers, as I see it, need definite texts.
> And rejection of the "lawyer's" sort of texts is not surprising.
> That not necessarily affects their acceptance will of more formal
> specifications.
You sniped most of what I wrote. I certainly would prefer standard
that is less lawyerish and more mathematical, say written in similar
way to Pascal standard. But there is a _big_ gap between normal
mathematical text and a formal mathematical text (and let me note that
Pascal standard is less formal than normal mathematics). Normal
mathematical text depends on human understanding to disambiguate
and bridge small inconsistencies. Formal one has parts which
are there only because authors were not able to avoid
ambiguity in simpler way. And once things are written in a way
that is well fit to formalizm they tend to be much less
understandable to uninitiated.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-06-11 20:52 +0200 |
| Subject | Re: Constants and undefined behavior |
| Message-ID | <110f05e$1nauc$8@dont-email.me> |
| In reply to | #399905 |
On 2026-06-11 18:30, Waldek Hebisch wrote: > Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote: >> On 2026-06-09 03:25, Waldek Hebisch wrote: >>> [...] >> >> Interesting views. - Thanks. >> >>> >>> I think biggest trouble is normal programmers. They already >>> struggle with current standard text. More formal presentation >>> could alienate even folks who now are able to explain standard >>> rules to other programmers. >> >> I'm not sure what "normal programmers" are. From own experience >> I can just say that there's a difference between what's "formal" >> in a "lawyer's speeches and texts" sense and what's formal in a >> mathematical sense. - The C-Standard as had been quoted here is >> more of a lawyer's text, with its inherent property of not being >> formally (in a mathematical sense) accurate (despite their tries; >> in both areas, law and programming language, respectively). It's >> thus not necessarily a problem if we'd have a more [mathematical] >> formal standard. - Programmers, as I see it, need definite texts. >> And rejection of the "lawyer's" sort of texts is not surprising. >> That not necessarily affects their acceptance will of more formal >> specifications. > > You sniped most of what I wrote. Yes, because I acknowledged it by my above on-line remark already (and I didn't want to waste space unnecessarily). (No offense!) I intended to comment just on the one paragraph above, with its assumption that it may be an inherent problem to programmers. To elaborate only a bit more... There's folks who have problems with "lawyer's speech" standards. There's folks who have problems with formal mathematical standards. But, as to my observation, there's *no* strict or natural hierarchy that one would imply the other. You said: "They already struggle with current standard text." as if there would be a strict "one implies the other" fact; there isn't one, or to be more cautious, "there isn't necessarily one". (I used the wording "necessarily" already in my original comment.) > I certainly would prefer standard > that is less lawyerish and more mathematical, say written in similar > way to Pascal standard. But there is a _big_ gap between normal > mathematical text and a formal mathematical text (and let me note that > Pascal standard is less formal than normal mathematics). I agree. > Normal > mathematical text depends on human understanding to disambiguate > and bridge small inconsistencies. Formal one has parts which > are there only because authors were not able to avoid > ambiguity in simpler way. And once things are written in a way > that is well fit to formalizm they tend to be much less > understandable to uninitiated. (I'll leave that uncommented. - I've said all I intended to say.) Janis
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2026-06-12 02:20 +0000 |
| Subject | Re: Constants and undefined behavior |
| Message-ID | <110fqco$1ck3s$3@paganini.bofh.team> |
| In reply to | #399909 |
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
> On 2026-06-11 18:30, Waldek Hebisch wrote:
>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
>>> On 2026-06-09 03:25, Waldek Hebisch wrote:
>>>> [...]
>>>
>>> Interesting views. - Thanks.
>>>
>>>>
>>>> I think biggest trouble is normal programmers. They already
>>>> struggle with current standard text. More formal presentation
>>>> could alienate even folks who now are able to explain standard
>>>> rules to other programmers.
>>>
>>> I'm not sure what "normal programmers" are. From own experience
>>> I can just say that there's a difference between what's "formal"
>>> in a "lawyer's speeches and texts" sense and what's formal in a
>>> mathematical sense. - The C-Standard as had been quoted here is
>>> more of a lawyer's text, with its inherent property of not being
>>> formally (in a mathematical sense) accurate (despite their tries;
>>> in both areas, law and programming language, respectively). It's
>>> thus not necessarily a problem if we'd have a more [mathematical]
>>> formal standard. - Programmers, as I see it, need definite texts.
>>> And rejection of the "lawyer's" sort of texts is not surprising.
>>> That not necessarily affects their acceptance will of more formal
>>> specifications.
>>
>> You sniped most of what I wrote.
>
> Yes, because I acknowledged it by my above on-line remark already
> (and I didn't want to waste space unnecessarily). (No offense!)
>
> I intended to comment just on the one paragraph above, with its
> assumption that it may be an inherent problem to programmers.
But this paragraph was closely linked to the text above. Dan Cross
wanted formal semantics and my paragraph was responding to this.
I think that lawyerish style of current C standard is mostly inertia,
and making standard more mathematical would improve it. But giving
formal semantic in the standard would mean significantly bigger
change.
> To elaborate only a bit more...
> There's folks who have problems with "lawyer's speech" standards.
> There's folks who have problems with formal mathematical standards.
> But, as to my observation, there's *no* strict or natural hierarchy
> that one would imply the other.
>
> You said: "They already struggle with current standard text."
> as if there would be a strict "one implies the other" fact; there
> isn't one, or to be more cautious, "there isn't necessarily one".
> (I used the wording "necessarily" already in my original comment.)
>
>> I certainly would prefer standard
>> that is less lawyerish and more mathematical, say written in similar
>> way to Pascal standard. But there is a _big_ gap between normal
>> mathematical text and a formal mathematical text (and let me note that
>> Pascal standard is less formal than normal mathematics).
>
> I agree.
>
>> Normal
>> mathematical text depends on human understanding to disambiguate
>> and bridge small inconsistencies. Formal one has parts which
>> are there only because authors were not able to avoid
>> ambiguity in simpler way. And once things are written in a way
>> that is well fit to formalizm they tend to be much less
>> understandable to uninitiated.
>
> (I'll leave that uncommented. - I've said all I intended to say.)
>
> Janis
>
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-06-13 14:57 +0200 |
| Subject | Re: Constants and undefined behavior |
| Message-ID | <110jk4g$2097v$5@dont-email.me> |
| In reply to | #399942 |
On 2026-06-12 04:20, Waldek Hebisch wrote: > Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote: >> On 2026-06-11 18:30, Waldek Hebisch wrote: >>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote: >>>> On 2026-06-09 03:25, Waldek Hebisch wrote: >>>>> [...] >>>> >>>> Interesting views. - Thanks. >>>> >>>>> >>>>> I think biggest trouble is normal programmers. They already >>>>> struggle with current standard text. More formal presentation >>>>> could alienate even folks who now are able to explain standard >>>>> rules to other programmers. >>>> >>>> I'm not sure what "normal programmers" are. From own experience >>>> I can just say that there's a difference between what's "formal" >>>> in a "lawyer's speeches and texts" sense and what's formal in a >>>> mathematical sense. - The C-Standard as had been quoted here is >>>> more of a lawyer's text, with its inherent property of not being >>>> formally (in a mathematical sense) accurate (despite their tries; >>>> in both areas, law and programming language, respectively). It's >>>> thus not necessarily a problem if we'd have a more [mathematical] >>>> formal standard. - Programmers, as I see it, need definite texts. >>>> And rejection of the "lawyer's" sort of texts is not surprising. >>>> That not necessarily affects their acceptance will of more formal >>>> specifications. >>> >>> You sniped most of what I wrote. >> >> Yes, because I acknowledged it by my above on-line remark already >> (and I didn't want to waste space unnecessarily). (No offense!) >> >> I intended to comment just on the one paragraph above, with its >> assumption that it may be an inherent problem to programmers. > > But this paragraph was closely linked to the text above. Dan Cross > wanted formal semantics and my paragraph was responding to this. > I think that lawyerish style of current C standard is mostly inertia, > and making standard more mathematical would improve it. But giving > formal semantic in the standard would mean significantly bigger > change. Yes, you said that, and I had acknowledged that; meanwhile twice. I'm not sure why you persistently insist on any relation to your previous text when all what *I* wanted to comment on in your post was just _one aspect_ in your last paragraph, which was: >>>>> I think biggest trouble is normal programmers. >>>>> They already struggle with current standard text. And I expressed that I refute that view and I explained my view. If you think your statement about "normal programmers" (whatever you imply with "normal") is correct and my perception with people is in any way wrong we can discuss that. (On your other text I see nothing that we'd need to discuss.) Janis > [...]
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-06-21 15:26 -0700 |
| Subject | Re: Constants and undefined behavior |
| Message-ID | <868q878r8k.fsf@linuxsc.com> |
| In reply to | #399942 |
antispam@fricas.org (Waldek Hebisch) writes: [...] > I think that lawyerish style of current C standard is mostly > inertia, I wouldn't use a term like lawyerish to describe the text in the ISO C standard. Can you explain what quality you mean to ascribe to "lawyerish" writing in the C standard without using any term related to lawyering or legal documents? > and making standard more mathematical would improve it. Could you elaborate on that statement? In what ways would giving a more mathematical treatment of C semantics improve the quality of the ISO C document? How would doing that advance the stated purposes or goals of the C standard? > But giving formal semantic in the standard would mean > significantly bigger change. Due to the nature of C, I believe it is effectively impossible to give a formal mathematical definition of the semantics of C. Do you think such a thing is feasible or practicable? If so can you explain the reasoning behind your thinking?
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2026-06-22 03:40 +0000 |
| Subject | Re: Constants and undefined behavior |
| Message-ID | <111aas6$vtir$1@paganini.bofh.team> |
| In reply to | #400176 |
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
> antispam@fricas.org (Waldek Hebisch) writes:
>
> [...]
>
>> I think that lawyerish style of current C standard is mostly
>> inertia,
>
> I wouldn't use a term like lawyerish to describe the text in the
> ISO C standard. Can you explain what quality you mean to ascribe
> to "lawyerish" writing in the C standard without using any term
> related to lawyering or legal documents?
Sorry no, I can not. My point is that you need to treat
C standard almost like legal document and I can not explain
this without using proper terminology.
>> and making standard more mathematical would improve it.
>
> Could you elaborate on that statement? In what ways would giving
> a more mathematical treatment of C semantics improve the quality
> of the ISO C document? How would doing that advance the stated
> purposes or goals of the C standard?
There are many aspect of mathematical treatment. One is care
about terminology, namely that terms are either reasonably
clearly marked as "primitve" (and assumed to be understood
by readers) or are precisely defined. Related is that
words can be taken as written, without needing to look at
intent or similar legal style arguments. You may think that
C standard already posseses such properties, but recent
example, that is definition of expression nicely illustrates
current problems. With mathematical treatment expression
would be part of C program derived from corresponding
grammar rule and that would resolve the problem. In the
past in this group there were several discussions about
various parts of C standard, and there were cases were
standard wording looked genuinly confusing. I am not
prepared to dig into those discussions, but my impression
was that in some cases mathematical treatment would make
things clearer.
>> But giving formal semantic in the standard would mean
>> significantly bigger change.
>
> Due to the nature of C, I believe it is effectively impossible to
> give a formal mathematical definition of the semantics of C. Do
> you think such a thing is feasible or practicable? If so can you
> explain the reasoning behind your thinking?
I think that this is possible given dedicated team of qualified
people doing the work. I do not know if it is practically
possible to assemble needed team. I already mentioned axiomatic
semantics. There is C grammar and we need to assign semantics
to various production rules. We do this assigning precondtions
and postcondtions to the rules. In much simpler cases this
was done. C is bigger language and rules are more complicated,
but that for me looks like quantitive problem, that is there is
more work and result will be bigger. Clearly, this would
require buy-in from the standard body. Namely, formalization
is likely to uncover many unclear places in C standard and
ensuring that formalization matches the standard would require
resolution by the standard body. It is quite possible that
standard body would refuse to cooperate. To explain this more,
let me mention past discussion about Extended Pascal in a
different forum. I was looking at types of constants, but in
specific case rules looked contradictory, so I asked a
question. One response was from former commitee member (this
was several years after Pascal standard was ratified), he
basicaly said that type of constants does not matter. Which
was mostly true, but my reason for asking the question was
that validity of programs depended on types of constants.
Something similar may happen during formalization:
formalization may discover unclear places in C standard
which C commitee considers irrelevant in practice and
refuses to clarify.
BTW: Authors of some tools already need and have formal
semantics for language rather close to C. Namely,
Comp-Cert compiler is matching conditions in source
code with machine code and for that it needs reasonably
good aproximation to formal semantics of language implemented
by C compiler (more precisely gcc). Microsoft developed
formal checking tools and that too needs formal semantics.
But since goals are different neither give semantics of
standard C.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-08-15 07:50 -0700 |
| Subject | Re: Constants and undefined behavior |
| Message-ID | <867blr5tfv.fsf@linuxsc.com> |
| In reply to | #400181 |
antispam@fricas.org (Waldek Hebisch) writes: > Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > >> antispam@fricas.org (Waldek Hebisch) writes: >> >> [...] >> >>> I think that lawyerish style of current C standard is mostly >>> inertia, >> >> I wouldn't use a term like lawyerish to describe the text in the >> ISO C standard. Can you explain what quality you mean to ascribe >> to "lawyerish" writing in the C standard without using any term >> related to lawyering or legal documents? > > Sorry no, I can not. My point is that you need to treat > C standard almost like legal document and I can not explain > this without using proper terminology. > >>> and making standard more mathematical would improve it. >> >> Could you elaborate on that statement? In what ways would giving >> a more mathematical treatment of C semantics improve the quality >> of the ISO C document? How would doing that advance the stated >> purposes or goals of the C standard? > > There are many aspect of mathematical treatment. One is care > about terminology, namely that terms are either reasonably > clearly marked as "primitve" (and assumed to be understood > by readers) or are precisely defined. Related is that > words can be taken as written, without needing to look at > intent or similar legal style arguments. You may think that > C standard already posseses such properties, but recent > example, that is definition of expression nicely illustrates > current problems. With mathematical treatment expression > would be part of C program derived from corresponding > grammar rule and that would resolve the problem. In the > past in this group there were several discussions about > various parts of C standard, and there were cases were > standard wording looked genuinly confusing. I am not > prepared to dig into those discussions, but my impression > was that in some cases mathematical treatment would make > things clearer. > >>> But giving formal semantic in the standard would mean >>> significantly bigger change. >> >> Due to the nature of C, I believe it is effectively impossible to >> give a formal mathematical definition of the semantics of C. Do >> you think such a thing is feasible or practicable? If so can you >> explain the reasoning behind your thinking? > > I think that this is possible given dedicated team of qualified > people doing the work. I do not know if it is practically > possible to assemble needed team. I already mentioned axiomatic > semantics. There is C grammar and we need to assign semantics > to various production rules. We do this assigning precondtions > and postcondtions to the rules. In much simpler cases this > was done. C is bigger language and rules are more complicated, > but that for me looks like quantitive problem, that is there is > more work and result will be bigger. Clearly, this would > require buy-in from the standard body. Namely, formalization > is likely to uncover many unclear places in C standard and > ensuring that formalization matches the standard would require > resolution by the standard body. It is quite possible that > standard body would refuse to cooperate. To explain this more, > let me mention past discussion about Extended Pascal in a > different forum. I was looking at types of constants, but in > specific case rules looked contradictory, so I asked a > question. One response was from former commitee member (this > was several years after Pascal standard was ratified), he > basicaly said that type of constants does not matter. Which > was mostly true, but my reason for asking the question was > that validity of programs depended on types of constants. > Something similar may happen during formalization: > formalization may discover unclear places in C standard > which C commitee considers irrelevant in practice and > refuses to clarify. > > BTW: Authors of some tools already need and have formal > semantics for language rather close to C. Namely, > Comp-Cert compiler is matching conditions in source > code with machine code and for that it needs reasonably > good aproximation to formal semantics of language implemented > by C compiler (more precisely gcc). Microsoft developed > formal checking tools and that too needs formal semantics. > But since goals are different neither give semantics of > standard C. A disappointing response. You can't explain what you mean. The properties ascribed to a mathematical writing might just as well be met by more clearly written English. About defining a formal semantics, all you really say is you think it is possible, under some not very well defined conditions. All in all not too compelling.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-06-21 14:26 -0700 |
| Subject | Re: Constants and undefined behavior |
| Message-ID | <86cxxj8u1b.fsf@linuxsc.com> |
| In reply to | #399803 |
antispam@fricas.org (Waldek Hebisch) writes: > Dan Cross <cross@spitfire.i.gajendra.net> wrote: > >> In article <1100g0e$1lt8i$1@kst.eternal-september.org>, >> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: >> >>>>> and in fact >>>>> it *won't* occur during execution because foo() isn't called. >>>>> A compiler can't generate code with arbitrary behavior just >>>>> because it can't prove that there will be no UB. If it could, >>>>> every signed or floating-point arithmetic operation with unknown >>>>> operand values would grant the same permission. >>>> >>>> But that's not the situation here. The situation is that the >>>> compiler can prove that something _is_ UB. >>> >>> In the program quoted at the top of this post, the UB occurs in >>> a function foo() that's never called. A compiler can replace the >>> body of foo() with a trap, and it can certainly warn about the UB, >>> but I don't believe it can reject the entire program. A clever >>> compiler could prove that the UB never occurs. >> >> So there are two things that are at play here. >> >> First, this notion that UB is _only_ a runtime matter. The text >> of the standard contradicting that aside, if a translator can >> detect that the behavior of a construct is provably undefined if >> executed, then it seems axiomatic that UB is clearly something >> that plays a role at translation time, as well. > > I think that this paragraph (and several other it this post and > other posts) represent fundamental misanderstanding. This may > be due to the way C standard is written. AFAIK Extended Pascal > standard (once you translate terminalogy) states the same things as > C about UB, but in clearer way. Some relevant parts below: > > : 3.1 Dynamic-violation > : A violation by a program of the requirements of this International > : Standard that a processor is permitted to leave undetected up to, > : but not beyond, execution of the declaration, definition, or > : statement that exhibits (see clause 6) the dynamic-violation. > > : 3.2 Error > : A violation by a program of the requirements of this International > : Standard that a processor is permitted to leave undetected. > ... > : 5.1 Processors > ... > : e) be able to determine whether or not the program violates any > : requirements of this International Standard, where such a > violation is : not designated an error or dynamic-violation, > ... > > : 5.2 Programs > ... > : b) if it conforms at level 1, use only those features of the > language : specified in clause 6; > > UB in C standard corresponds with 'error' in Pascal standard. [...] Does it? In C a syntax error is undefined behavior, but it requires a diagnostic. (I don't mean to single out just syntax errors; there are other examples.)
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2026-06-22 03:56 +0000 |
| Subject | Re: Constants and undefined behavior |
| Message-ID | <111abp6$vtir$2@paganini.bofh.team> |
| In reply to | #400175 |
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
> antispam@fricas.org (Waldek Hebisch) writes:
>
>> Dan Cross <cross@spitfire.i.gajendra.net> wrote:
>>
>>> In article <1100g0e$1lt8i$1@kst.eternal-september.org>,
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>>
>>>>>> and in fact
>>>>>> it *won't* occur during execution because foo() isn't called.
>>>>>> A compiler can't generate code with arbitrary behavior just
>>>>>> because it can't prove that there will be no UB. If it could,
>>>>>> every signed or floating-point arithmetic operation with unknown
>>>>>> operand values would grant the same permission.
>>>>>
>>>>> But that's not the situation here. The situation is that the
>>>>> compiler can prove that something _is_ UB.
>>>>
>>>> In the program quoted at the top of this post, the UB occurs in
>>>> a function foo() that's never called. A compiler can replace the
>>>> body of foo() with a trap, and it can certainly warn about the UB,
>>>> but I don't believe it can reject the entire program. A clever
>>>> compiler could prove that the UB never occurs.
>>>
>>> So there are two things that are at play here.
>>>
>>> First, this notion that UB is _only_ a runtime matter. The text
>>> of the standard contradicting that aside, if a translator can
>>> detect that the behavior of a construct is provably undefined if
>>> executed, then it seems axiomatic that UB is clearly something
>>> that plays a role at translation time, as well.
>>
>> I think that this paragraph (and several other it this post and
>> other posts) represent fundamental misanderstanding. This may
>> be due to the way C standard is written. AFAIK Extended Pascal
>> standard (once you translate terminalogy) states the same things as
>> C about UB, but in clearer way. Some relevant parts below:
>>
>> : 3.1 Dynamic-violation
>> : A violation by a program of the requirements of this International
>> : Standard that a processor is permitted to leave undetected up to,
>> : but not beyond, execution of the declaration, definition, or
>> : statement that exhibits (see clause 6) the dynamic-violation.
>>
>> : 3.2 Error
>> : A violation by a program of the requirements of this International
>> : Standard that a processor is permitted to leave undetected.
>> ...
>> : 5.1 Processors
>> ...
>> : e) be able to determine whether or not the program violates any
>> : requirements of this International Standard, where such a
>> violation is : not designated an error or dynamic-violation,
>> ...
>>
>> : 5.2 Programs
>> ...
>> : b) if it conforms at level 1, use only those features of the
>> language : specified in clause 6;
>>
>> UB in C standard corresponds with 'error' in Pascal standard. [...]
>
> Does it? In C a syntax error is undefined behavior, but it
> requires a diagnostic. (I don't mean to single out just syntax
> errors; there are other examples.)
I mean typical UB, especialy cases that people complain about.
It does not help that C uses the same term in few other cases,
which are really different.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-06-29 06:27 -0700 |
| Subject | Re: Constants and undefined behavior |
| Message-ID | <86ik7179zi.fsf@linuxsc.com> |
| In reply to | #400182 |
antispam@fricas.org (Waldek Hebisch) writes: > Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > >> antispam@fricas.org (Waldek Hebisch) writes: [...] >>> UB in C standard corresponds with 'error' in Pascal standard. [...] >> >> Does it? In C a syntax error is undefined behavior, but it >> requires a diagnostic. (I don't mean to single out just syntax >> errors; there are other examples.) > > I mean typical UB, especialy cases that people complain about. > [...] Then you should say what you mean, rather than leaving it for other people to guess.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-06-06 15:47 -0700 |
| Subject | Re: Constants and undefined behavior |
| Message-ID | <86v7bv9thw.fsf@linuxsc.com> |
| In reply to | #399731 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > I claim that an expression that looks like a constant expression > *isn't* a constant-expression if it doesn't appear in a context > that requires a constant-expression. Right. This question came up years ago in a Defect Report. The response from the Committee was basically the same as what you said: the 6.6 constraints for constant expressions apply only in situations where the C standard expressly requires a constant expression. (I don't have the DR in front of me; I'm summarizing based on memory, but am confident the actual wording is consistent with what I just said.)
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-06-06 16:36 -0700 |
| Subject | Re: Constants and undefined behavior |
| Message-ID | <1102ate$25nse$1@kst.eternal-september.org> |
| In reply to | #399772 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> I claim that an expression that looks like a constant expression
>> *isn't* a constant-expression if it doesn't appear in a context
>> that requires a constant-expression.
>
> Right. This question came up years ago in a Defect Report. The
> response from the Committee was basically the same as what you
> said: the 6.6 constraints for constant expressions apply only in
> situations where the C standard expressly requires a constant
> expression. (I don't have the DR in front of me; I'm summarizing
> based on memory, but am confident the actual wording is consistent
> with what I just said.)
C99 DR 261 looks similar to what you're talking about.
https://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_261.htm
The Committee Response section says:
In general, the interpretation of an expression for constantness
is context sensitive. For any expression which contains only
constants:
- If the syntax or context only permits a constant expression, the
constraints of 6.6#3 and 6.6#4 shall apply.
- Otherwise, if the expression meets the requirements of 6.6
(including any form accepted in accordance with 6.6#10), it is a
constant expression.
- Otherwise it is not a constant expression.
That's close to what I claimed, but the second bullet point differs.
My claim was that, given:
n = 2+2;
2+2 is not a constant expression because the grammar doesn't require
a constant expression in that context. The Committee's opinion
(at least at the time) was that it is a constant expression because
it meets the requirements of 6.6.
But I *think* it's a distinction without a difference. Calling 2+2
a constant expression has no effect on the semantics, and does not
require or forbid the implementation from, for example, generating
an ADD instruction. The distinction would matter for an expression
that has UB and/or does not yield a value of the type, but that
falls through to the third bullet.
I found another interesting tidbit, C90 DR 031, relevant to another
point I made elsethread:
https://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_031.html
case (INT_MAX*4)/4: is a constraint violation.
When subclause 6.4 says on page 55, lines 11-12:
Each constant expression shall evaluate to a constant that is in
the range of representable values for its type.
the Committee's judgement of the intent is that the
``representable'' requirement applies to each subexpression of a
constant expression, as shown in the third example. A constant
expression is meant as defined by the syntax rules.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-06-06 16:43 -0700 |
| Subject | Re: Constants and undefined behavior |
| Message-ID | <86mrx79qva.fsf@linuxsc.com> |
| In reply to | #399776 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > >> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: >> >>> I claim that an expression that looks like a constant expression >>> *isn't* a constant-expression if it doesn't appear in a context >>> that requires a constant-expression. >> >> Right. This question came up years ago in a Defect Report. The >> response from the Committee was basically the same as what you >> said: the 6.6 constraints for constant expressions apply only in >> situations where the C standard expressly requires a constant >> expression. (I don't have the DR in front of me; I'm summarizing >> based on memory, but am confident the actual wording is consistent >> with what I just said.) > > C99 DR 261 looks similar to what you're talking about. > > https://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_261.htm > > The Committee Response section says: > > In general, the interpretation of an expression for constantness > is context sensitive. For any expression which contains only > constants: > > - If the syntax or context only permits a constant expression, the > constraints of 6.6#3 and 6.6#4 shall apply. > - Otherwise, if the expression meets the requirements of 6.6 > (including any form accepted in accordance with 6.6#10), it is a > constant expression. > - Otherwise it is not a constant expression. > > That's close to what I claimed, but the second bullet point differs. > My claim was that, given: > > n = 2+2; > > 2+2 is not a constant expression because the grammar doesn't require > a constant expression in that context. The Committee's opinion > (at least at the time) was that it is a constant expression because > it meets the requirements of 6.6. > > But I *think* it's a distinction without a difference. [...] Right. The key point is that the constraints need to be satisfied only in situations where the C standard expressly requires a constant expression. Whether a given expression is called a "constant expression" doesn't matter; all that does matter is whether the constraints need to be satisfied.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-06-06 17:41 -0700 |
| Subject | Re: Constants and undefined behavior |
| Message-ID | <1102enu$26qtr$1@kst.eternal-september.org> |
| In reply to | #399777 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
[...]
>> That's close to what I claimed, but the second bullet point differs.
>> My claim was that, given:
>>
>> n = 2+2;
>>
>> 2+2 is not a constant expression because the grammar doesn't require
>> a constant expression in that context. The Committee's opinion
>> (at least at the time) was that it is a constant expression because
>> it meets the requirements of 6.6.
>>
>> But I *think* it's a distinction without a difference. [...]
>
> Right. The key point is that the constraints need to be satisfied
> only in situations where the C standard expressly requires a
> constant expression. Whether a given expression is called a
> "constant expression" doesn't matter; all that does matter is
> whether the constraints need to be satisfied.
Well, it matters a little bit, at least to me, even though the
distinction doesn't seem to affect the validity or semantics of
any C code.
A clear and unambiguous definition of what is or is not a "constant
expression" would make the language just a bit easier to understand
and explain. I'd even be satisified with the definition given in
the DR *if* it were clearly expressed in the standard.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-06-05 10:41 +0200 |
| Subject | Re: Constants and undefined behavior |
| Message-ID | <10vu236$fm4o$4@dont-email.me> |
| In reply to | #399725 |
On 2026-06-05 01:49, Dan Cross wrote: >> [...] > [...] > [ ... (INT_MAX+1)*0 ] > Furthermore, the expression above is obviously an integer > constant expression as defined by sec 6.6 para 8. Section 6.6, > para 4, reads in part, "Each constant expression shall evaluate > to a constant that is in the range of representable values for > its type." The expression, `(INT_MAX+1)*0` violates this > constraint, and so therefore a diagnostic is mandated as per > sec 5.1.1.3 para 1. That it appears in code that is not > obviously called from `main` doesn't change that. I'm curious about that "violation"; a violation would require (at least) two sorts of logical preconditions. - The first is that all *sequentially* (literally) evaluated sub-expression values are representable as value - INT_MAX+1 certainly can't be represented in generated code that conforms to the abstract *mathematical* value - but is that necessary if _the whole_ expression is (mathematically) just 0 (because of the final factor). And the second (related) is whether the order of the sub-expression evaluation is relevant; if we'd assume the expression evaluation to be considered from right to left then it would be irrelevant what's inside the parenthesis. From the standard quotes I cannot really recognize that these preconditions, how to determine UB/errors/violations, would be necessary. I'm no native speaker and I fear my question as formulated was hard to understand. It's basically the question of the standard implying (INT_MAX+1)*0 to be analyzed sequentially as written or whether it could as well analyze it from right to left and thus recognizing no problem, since from the mathematical view - but also practically - a concrete representable value of a here irrelevant sub-expression isn't necessary. Or another try of a (paraphrased) formulation; for the determination of constraint violations does the expression have strict (sort of) sequencing points _after each term_ (and each left-to-right sub-expression has to be well-defined) or can it be valued/analyzed as a whole not putting any preconditions about evaluation order etc. when determining the overall value? Janis PS: One yet non-considered question that was part of my original post was: "Is there any rationale from the _software designer_'s perspective?" > [...]
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-06-05 10:49 -0700 |
| Subject | Re: Constants and undefined behavior |
| Message-ID | <10vv27c$1aoa2$1@kst.eternal-september.org> |
| In reply to | #399741 |
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
> On 2026-06-05 01:49, Dan Cross wrote:
>>> [...]
>> [...]
>
>> [ ... (INT_MAX+1)*0 ]
>
>> Furthermore, the expression above is obviously an integer
>> constant expression as defined by sec 6.6 para 8. Section 6.6,
>> para 4, reads in part, "Each constant expression shall evaluate
>> to a constant that is in the range of representable values for
>> its type." The expression, `(INT_MAX+1)*0` violates this
>> constraint, and so therefore a diagnostic is mandated as per
>> sec 5.1.1.3 para 1. That it appears in code that is not
>> obviously called from `main` doesn't change that.
>
> I'm curious about that "violation"; a violation would require
> (at least) two sorts of logical preconditions. - The first is
> that all *sequentially* (literally) evaluated sub-expression
> values are representable as value - INT_MAX+1 certainly can't
> be represented in generated code that conforms to the abstract
> *mathematical* value - but is that necessary if _the whole_
> expression is (mathematically) just 0 (because of the final
> factor). And the second (related) is whether the order of the
> sub-expression evaluation is relevant; if we'd assume the
> expression evaluation to be considered from right to left then
> it would be irrelevant what's inside the parenthesis.
If the expression were evaluated right to left, it would still
compute INT_MAX+1, which is UB.
Let's look at an example where it's not in a context that requires a
constant expression:
int n;
n = (INT_MAX+1)*0;
In the abstract machine, the RHS is evaluated by adding INT_MAX
and 1 (which overflows, UB) and then multiplying the result by 0.
A compiler is allowed, but not required, to reduce the assignment to
`n = 0;`. If it does so, then no overflow occurs at run time --
but the definedness of the behavior is determined independent of
any optimizations. The C standard does not require any particular
behavior. It can set n to 0 because that's a valid consequence
of UB.
Let's take an example where it's definitely in a context that
requires an integer constant expression:
switch (0) {
case (INT_MAX+1)*0:
break;
}
The wording in 6.6 (Constant expressions) is slightly vague.
For example, I would assume that any subexpression of a constant
expression must be a constant expression, but it doesn't actually
say so.
But since, in the abstract machine, (INT_MAX+1)*0 doesn't yield
any defined value, I'd say it violates the constraint that "Each
constant expression shall evaluate to a constant that is in the
range of representable values for its type".
The alternative would be for to be a constant expression for
implementations that are able to recognize that anything multiplied
by zero is zero (analysis that compilers aren't required to perform),
and not for others.
On the other hand, "An implementation may accept other forms of
constant expressions; however, it is implementation-defined whether
they are an integer constant expression." That probably allows,
but does not reuqire, an implementation to treat (INT_MAX+1)*0 as
a constant expression with the value 0.
> From the standard quotes I cannot really recognize that these
> preconditions, how to determine UB/errors/violations, would be
> necessary.
>
> I'm no native speaker and I fear my question as formulated was
> hard to understand. It's basically the question of the standard
> implying (INT_MAX+1)*0 to be analyzed sequentially as written
> or whether it could as well analyze it from right to left and
> thus recognizing no problem, since from the mathematical view -
> but also practically - a concrete representable value of a here
> irrelevant sub-expression isn't necessary. Or another try of a
> (paraphrased) formulation; for the determination of constraint
> violations does the expression have strict (sort of) sequencing
> points _after each term_ (and each left-to-right sub-expression
> has to be well-defined) or can it be valued/analyzed as a whole
> not putting any preconditions about evaluation order etc. when
> determining the overall value?
>
> PS: One yet non-considered question that was part of my original
> post was: "Is there any rationale from the _software designer_'s
> perspective?"
From a programmer's perspective, it's good to have consistent
rules rather than leaving the decision of whether an expression
is a constant expression up to the undocumented vagaries of how
clever a compiler happens to be.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-06-06 16:15 -0700 |
| Subject | Re: Constants and undefined behavior |
| Message-ID | <86qzmj9s7a.fsf@linuxsc.com> |
| In reply to | #399741 |
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
> PS: One yet non-considered question that was part of my original
> post was: "Is there any rationale from the _software designer_'s
> perspective?"
I didn't respond to your original question because it was based on a
misconception. Whether a given expression is a constant expression,
in the sense of needing to satisfy the constraints of 6.6, depends
not on the form of the expression but on the context in which it
appears. The 6.6 constraints apply only in situations where the C
standard expressly requires a constant expression. Other cases,
such as a use like this
int
whatever(){
int r = (int)(-1u/2) + 1;
return r;
}
do not need to satisfy the 6.6 constraints, because the C standard
doesn't require a constant expression in that context. (Note that
the initializing expression for 'r' does overflow the range of int
in implementations where UINT_MAX == INT_MAX*2.)
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-06-06 18:06 -0700 |
| Subject | Re: Constants and undefined behavior |
| Message-ID | <86ik7v9n1e.fsf@linuxsc.com> |
| In reply to | #399710 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> cross@spitfire.i.gajendra.net (Dan Cross) writes:
>
>> In article <865x3yd21n.fsf@linuxsc.com>,
>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>>
>>> cross@spitfire.i.gajendra.net (Dan Cross) writes:
>>>
>>>> In article <86ik81cfk5.fsf_-_@linuxsc.com>,
>>>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>
> [...]
>
>>>>> There's an important distinction to make here. Consider this
>>>>> program:
>>>>>
>>>>> #include <limits.h>
>>>>>
>>>>> int
>>>>> foo(){
>>>>> int zero = (INT_MAX+1)*0;
>>>>> return zero;
>>>>> }
>>>>>
>>>>> int
>>>>> main(){
>>>>> return 0;
>>>>> }
>>>>>
>>>>> This program does not transgress the bounds of undefined behavior.
>>>
>>> To clarify, the comments in my posting were meant to be read as
>>> saying the given text is the entire program, and that it is strictly
>>> conforming with respect to conforming hosted implementations.
>>> (Incidentally, given the rules for freestanding implementations, I'm
>>> not sure that it is even possible for any program to be strictly
>>> conforming with respect to conforming freestanding implementations.
>>> In any case my statements were meant only in the context of hosted
>>> implementations.)
[...]
> foo() has undefined behavior if it's called, so replacing its
> body with trapping code is valid.
Right.
> But (I'm reasonably sure that)
> an implementation cannot reject a program just because it can't
> prove that it has no undefined behavior during execution. [...]
Right.
>> In your example, `foo` clearly exhibits UB; I think your
>> argument is whether that has a realized effect or not, since the
>> UB is not invoked. I'm saying that in general a compiler cannot
>> possibly know that when it compiles `foo`, and is free to assume
>> the worst.
>
> foo() exhibits UB if and only if it's called during execution.
Right.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-06-07 22:34 -0700 |
| Subject | Re: Constants and undefined behavior |
| Message-ID | <867bo9a937.fsf@linuxsc.com> |
| In reply to | #399779 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: [...] >> But (I'm reasonably sure that) >> an implementation cannot reject a program just because it can't >> prove that it has no undefined behavior during execution. [...] > > Right. Expanding on that, there is no requirement even to try to prove such a conjecture. An implementation could simply give a warning like "there may be undiagnosed constraint violations in this compilation", and accept the TU no matter what (except of course for the dreaded #error preprocessing directive, which if encountered in a live portion of the translation must result in a rejection). I presume none of what I'm saying here is news to the usual suspects; mostly I'm saying it just to remind myself.
[toc] | [prev] | [next] | [standalone]
Page 6 of 23 — ← Prev page 1 … 4 5 [6] 7 8 … 23 Next page →
Back to top | Article view | comp.lang.c
csiph-web