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 463 — 24 participants |
Back to article view | Back to comp.lang.c
this girl calls c ugly fir <profesor.fir@gmail.com> - 2026-05-27 19:53 +0200
Re: this girl calls c ugly fir <profesor.fir@gmail.com> - 2026-05-27 20:15 +0200
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-27 18:49 -0500
Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-28 04:53 +0000
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-28 02:35 -0500
Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-28 23:32 +0000
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-28 20:07 -0500
Re: this girl calls c ugly Bonita Montero <Bonita.Montero@gmail.com> - 2026-05-28 11:48 +0200
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-28 09:18 +0200
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-28 04:57 -0500
Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-28 23:35 +0000
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 09:52 +0200
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-29 05:20 -0500
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-29 13:22 +0200
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-29 15:16 -0500
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-30 13:52 +0200
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-30 14:40 +0200
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-30 16:36 +0200
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-30 15:48 -0500
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-31 11:14 +0200
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-31 13:25 -0500
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-31 22:14 +0200
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 15:22 +0200
Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-30 03:49 +0000
Re: this girl calls c ugly "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-05-28 12:47 -0700
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 09:56 +0200
Re: this girl calls c ugly "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-05-29 11:00 -0700
Re: this girl calls c ugly fir <profesor.fir@gmail.com> - 2026-05-28 17:12 +0200
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-28 14:07 -0500
Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-28 23:54 +0000
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 10:02 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 12:19 +0100
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 14:46 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 14:22 +0100
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 17:15 +0200
Re: this girl calls c ugly scott@slp53.sl.home (Scott Lurndal) - 2026-05-29 15:59 +0000
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 17:12 +0100
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 18:48 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 19:09 +0100
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 22:00 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 22:14 +0100
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-29 12:09 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 17:05 +0100
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 18:34 +0200
Re: this girl calls c ugly tTh <tth@none.invalid> - 2026-05-29 19:29 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 18:53 +0100
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-29 12:28 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 20:49 +0100
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 22:03 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-29 13:56 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 22:54 +0100
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-29 15:52 -0700
Re: this girl calls c ugly James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-05-29 20:31 -0400
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-30 02:03 +0100
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-29 19:02 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-30 12:12 +0100
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-30 12:29 +0000
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-30 13:56 +0100
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-30 16:43 -0700
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-31 03:37 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-30 19:53 -0700
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-02 12:16 +0200
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-31 11:47 +0200
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-02 12:55 +0200
Re: this girl calls c ugly Richard Harnden <richard.nospam@gmail.invalid> - 2026-05-31 09:12 +0100
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-31 11:49 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-31 11:10 +0100
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-31 13:18 +0200
Re: this girl calls c ugly James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-05-31 10:24 -0400
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-31 17:35 +0200
Re: this girl calls c ugly James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-05-31 12:46 -0400
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-31 22:24 +0200
Re: this girl calls c ugly James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-05-31 18:26 -0400
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-01 08:28 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-31 15:54 -0700
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-01 08:39 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-01 02:33 -0700
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-02 11:48 +0200
Re: this girl calls c ugly James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-06-02 06:37 -0400
Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-02 05:06 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-02 16:28 +0000
Re: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-04 03:37 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-04 16:31 +0000
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-04 13:36 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-04 23:49 +0000
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-04 18:04 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-06 03:10 +0000
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-05 23:50 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-08 02:20 +0000
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-08 12:39 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-08 23:15 +0000
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-08 18:51 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-09 09:46 +0000
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-09 15:07 -0700
Re: Constants and undefined behavior antispam@fricas.org (Waldek Hebisch) - 2026-06-09 01:25 +0000
Re: Constants and undefined behavior James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-06-09 18:29 -0400
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-09 16:01 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-10 12:36 +0000
Re: Constants and undefined behavior Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-11 16:49 +0200
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-11 15:20 +0000
Re: Constants and undefined behavior Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-11 18:08 +0200
Re: Constants and undefined behavior antispam@fricas.org (Waldek Hebisch) - 2026-06-11 16:30 +0000
Re: Constants and undefined behavior Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-11 20:52 +0200
Re: Constants and undefined behavior antispam@fricas.org (Waldek Hebisch) - 2026-06-12 02:20 +0000
Re: Constants and undefined behavior Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-13 14:57 +0200
Re: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-21 15:26 -0700
Re: Constants and undefined behavior antispam@fricas.org (Waldek Hebisch) - 2026-06-22 03:40 +0000
Re: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-15 07:50 -0700
Re: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-21 14:26 -0700
Re: Constants and undefined behavior antispam@fricas.org (Waldek Hebisch) - 2026-06-22 03:56 +0000
Re: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-29 06:27 -0700
Re: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-06 15:47 -0700
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-06 16:36 -0700
Re: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-06 16:43 -0700
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-06 17:41 -0700
Re: Constants and undefined behavior Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-05 10:41 +0200
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-05 10:49 -0700
Re: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-06 16:15 -0700
Re: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-06 18:06 -0700
Re: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-07 22:34 -0700
Re: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-08 23:05 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-09 10:19 +0000
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-09 15:12 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-10 14:37 +0000
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-10 18:30 +0000
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-10 14:55 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-10 23:32 +0000
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-10 14:47 -0700
Re: Constants and undefined behavior David Brown <david.brown@hesbynett.no> - 2026-06-11 08:56 +0200
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-11 11:38 +0000
Re: Constants and undefined behavior David Brown <david.brown@hesbynett.no> - 2026-06-11 14:05 +0200
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-11 15:38 -0700
Re: Constants and undefined behavior scott@slp53.sl.home (Scott Lurndal) - 2026-06-11 23:07 +0000
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-11 17:43 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-12 02:02 +0000
Re: Constants and undefined behavior Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-11 17:34 +0200
Re: Constants and undefined behavior David Brown <david.brown@hesbynett.no> - 2026-06-12 10:58 +0200
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-12 12:27 -0700
Re: Constants and undefined behavior David Brown <david.brown@hesbynett.no> - 2026-06-13 12:36 +0200
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-13 12:03 +0000
Re: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-14 12:35 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-13 12:02 +0000
Re: Constants and undefined behavior ram@zedat.fu-berlin.de (Stefan Ram) - 2026-06-13 12:13 +0000
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-13 12:44 +0000
Re: Constants and undefined behavior ram@zedat.fu-berlin.de (Stefan Ram) - 2026-06-14 17:22 +0000
Re: Constants and undefined behavior scott@slp53.sl.home (Scott Lurndal) - 2026-06-14 21:24 +0000
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-15 17:52 +0000
Re: Constants and undefined behavior David Brown <david.brown@hesbynett.no> - 2026-06-13 18:32 +0200
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-14 14:33 +0000
Re: Constants and undefined behavior David Brown <david.brown@hesbynett.no> - 2026-06-14 22:02 +0200
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-14 15:55 -0700
Re: Constants and undefined behavior David Brown <david.brown@hesbynett.no> - 2026-06-15 10:09 +0200
Re: Constants and undefined behavior antispam@fricas.org (Waldek Hebisch) - 2026-06-15 10:43 +0000
Re: Constants and undefined behavior David Brown <david.brown@hesbynett.no> - 2026-06-15 16:01 +0200
Re: Constants and undefined behavior antispam@fricas.org (Waldek Hebisch) - 2026-06-15 17:57 +0000
Re: Constants and undefined behavior David Brown <david.brown@hesbynett.no> - 2026-06-16 10:10 +0200
Re: Constants and undefined behavior Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-24 17:45 +0200
Re: Constants and undefined behavior "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-24 12:27 -0700
Re: Constants and undefined behavior Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-24 16:58 +0200
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-15 19:26 +0000
Re: Constants and undefined behavior James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-06-15 21:59 -0400
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-16 04:59 +0000
Re: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-29 05:41 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-29 15:23 +0000
Re: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-15 07:36 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-08-18 20:27 +0000
Re: Constants and undefined behavior Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-20 04:12 +0800
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-11 13:29 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-12 02:08 +0000
Re: Constants and undefined behavior David Brown <david.brown@hesbynett.no> - 2026-06-12 11:02 +0200
Re: Constants and undefined behavior Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-11 17:45 +0200
Re: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-10 15:11 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-10 22:44 +0000
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-10 16:19 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-11 11:50 +0000
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-11 16:28 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-11 23:46 +0000
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-11 18:29 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-12 01:54 +0000
Re: Constants and undefined behavior David Brown <david.brown@hesbynett.no> - 2026-06-12 11:37 +0200
Re: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-15 07:58 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-08-18 20:28 +0000
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-02 05:35 -0700
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-02 06:29 -0700
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-02 16:10 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-02 15:29 -0700
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-05 06:41 -0700
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-05 11:24 -0700
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-08 08:35 -0700
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-08 17:33 +0000
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-09 00:54 -0700
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-09 10:08 +0000
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-08 13:40 -0700
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-15 09:37 -0700
Meaning of "expression" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-08 14:05 -0700
Expression statements (was Re: Meaning of "expression") Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-09 15:17 +0200
Re: Expression statements (was Re: Meaning of "expression") Bart <bc@freeuk.com> - 2026-06-09 14:53 +0100
Re: Expression statements (was Re: Meaning of "expression") Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-09 16:30 +0200
Re: Expression statements (was Re: Meaning of "expression") David Brown <david.brown@hesbynett.no> - 2026-06-09 17:13 +0200
Re: Expression statements (was Re: Meaning of "expression") Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-09 15:34 -0700
Re: Expression statements (was Re: Meaning of "expression") David Brown <david.brown@hesbynett.no> - 2026-06-10 09:04 +0200
Re: Expression statements (was Re: Meaning of "expression") Bart <bc@freeuk.com> - 2026-06-10 11:10 +0100
Re: Expression statements (was Re: Meaning of "expression") David Brown <david.brown@hesbynett.no> - 2026-06-10 13:29 +0200
Re: Expression statements (was Re: Meaning of "expression") Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-10 03:17 -0700
Re: Expression statements (was Re: Meaning of "expression") David Brown <david.brown@hesbynett.no> - 2026-06-10 13:43 +0200
Re: Expression statements (was Re: Meaning of "expression") Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-10 14:08 -0700
Re: Expression statements (was Re: Meaning of "expression") David Brown <david.brown@hesbynett.no> - 2026-06-11 09:10 +0200
Re: Expression statements (was Re: Meaning of "expression") Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-11 20:29 +0200
Re: Expression statements (was Re: Meaning of "expression") David Brown <david.brown@hesbynett.no> - 2026-06-12 12:55 +0200
Re: Expression statements (was Re: Meaning of "expression") Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-13 15:01 +0200
Re: Expression statements (was Re: Meaning of "expression") Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-11 20:12 +0200
Re: Expression statements (was Re: Meaning of "expression") James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-06-11 15:13 -0400
Re: Expression statements (was Re: Meaning of "expression") Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-12 00:37 +0200
Re: Expression statements (was Re: Meaning of "expression") scott@slp53.sl.home (Scott Lurndal) - 2026-06-11 23:05 +0000
Re: Expression statements (was Re: Meaning of "expression") Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-12 01:18 +0200
Re: Expression statements (was Re: Meaning of "expression") Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-11 17:41 -0700
Re: Expression statements (was Re: Meaning of "expression") Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-28 02:49 +0200
Re: Expression statements (was Re: Meaning of "expression") Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-27 21:00 -0700
Re: Expression statements (was Re: Meaning of "expression") Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-28 09:52 -0700
Re: Expression statements (was Re: Meaning of "expression") Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-28 18:28 -0700
Re: Expression statements (was Re: Meaning of "expression") Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-14 13:40 -0700
Re: Expression statements (was Re: Meaning of "expression") Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-14 14:13 -0700
Re: Expression statements (was Re: Meaning of "expression") Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-19 08:32 -0700
Re: Expression statements (was Re: Meaning of "expression") Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-19 15:09 -0700
Re: Expression statements (was Re: Meaning of "expression") James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-06-11 20:41 -0400
Re: Expression statements (was Re: Meaning of "expression") Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-28 03:16 +0200
Re: Expression statements (was Re: Meaning of "expression") tTh <tth@none.invalid> - 2026-06-09 19:27 +0200
Re: Expression statements (was Re: Meaning of "expression") Bart <bc@freeuk.com> - 2026-06-09 19:19 +0100
Re: Expression statements (was Re: Meaning of "expression") Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-09 15:22 -0700
Re: Meaning of "expression" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-15 00:42 -0700
The meaning of 42 ; (was: Re: Meaning of "expression") Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-15 19:42 +0800
Re: Meaning of "expression" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-15 05:36 -0700
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-06 03:22 +0000
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-05 23:56 -0700
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-07 13:37 +0000
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-07 15:09 -0700
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-08 02:33 +0000
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-15 09:37 -0700
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-15 17:29 -0700
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-08-18 20:30 +0000
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-08 00:16 -0700
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-08 12:41 +0000
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-08 17:37 +0000
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-09 16:05 +0200
Re: this girl calls c ugly "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-02 13:59 -0700
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-02 13:05 +0000
Parentheses (was: this girl calls c ugly) Bart <bc@freeuk.com> - 2026-06-02 14:38 +0100
Re: Parentheses (was: this girl calls c ugly) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-02 15:19 +0000
Re: Parentheses antispam@fricas.org (Waldek Hebisch) - 2026-06-03 22:30 +0000
Re: Parentheses Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-03 16:24 -0700
Re: Parentheses antispam@fricas.org (Waldek Hebisch) - 2026-06-04 02:03 +0000
Re: Parentheses Bart <bc@freeuk.com> - 2026-06-04 01:12 +0100
Re: Parentheses antispam@fricas.org (Waldek Hebisch) - 2026-06-04 01:58 +0000
Re: Parentheses Bart <bc@freeuk.com> - 2026-06-04 11:37 +0100
Re: Parentheses cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-04 10:51 +0000
Re: Parentheses Bart <bc@freeuk.com> - 2026-06-04 12:47 +0100
Re: Parentheses Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-04 14:57 +0200
Re: Parentheses cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-04 14:31 +0000
[OT] Fancy graphics (was Re: this girl calls c ugly) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-02 15:54 +0200
Re: [OT] Fancy graphics (was Re: this girl calls c ugly) Bart <bc@freeuk.com> - 2026-06-02 15:19 +0100
Re: [OT] Fancy graphics (was Re: this girl calls c ugly) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-02 15:19 +0000
Re: [OT] Fancy graphics (was Re: this girl calls c ugly) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-02 17:39 +0200
Re: [OT] Fancy graphics (was Re: this girl calls c ugly) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-02 16:36 +0000
Re: [OT] Fancy graphics (was Re: this girl calls c ugly) scott@slp53.sl.home (Scott Lurndal) - 2026-06-02 21:33 +0000
Re: [OT] Fancy graphics (was Re: this girl calls c ugly) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-02 14:43 -0700
Re: [OT] Fancy graphics (was Re: this girl calls c ugly) ram@zedat.fu-berlin.de (Stefan Ram) - 2026-06-02 17:08 +0000
Re: [OT] Fancy graphics (was Re: this girl calls c ugly) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-02 19:19 +0000
Re: [OT] Fancy graphics (was Re: this girl calls c ugly) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-04 00:11 +0000
Re: [OT] Fancy graphics (was Re: this girl calls c ugly) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-02 15:39 -0700
Re: [OT] Fancy graphics (was Re: this girl calls c ugly) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-03 13:14 +0000
Re: this girl calls c ugly scott@slp53.sl.home (Scott Lurndal) - 2026-06-02 15:10 +0000
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-02 15:31 +0000
Re: this girl calls c ugly James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-05-31 10:15 -0400
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-31 16:29 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-31 03:45 -0700
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-31 04:02 -0700
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-31 09:04 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-31 18:11 +0100
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-31 19:34 +0000
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-31 19:10 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-01 11:12 +0100
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-01 12:36 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-01 14:26 -0700
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-04 02:34 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-04 12:40 +0100
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-04 14:35 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-04 14:18 +0100
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-04 15:47 +0200
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-04 15:57 +0200
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-04 16:27 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-04 16:46 +0100
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-04 20:15 +0200
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-04 20:54 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-04 20:29 +0100
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-04 14:06 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-04 22:47 +0100
Famous (hopefully last) words [on this topic] Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-05 00:27 +0200
Re: Famous (hopefully last) words [on this topic] Bad Post <invalid@invalid.invalid> - 2026-06-05 01:20 +0100
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-04 16:09 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-05 00:44 +0100
Re: this girl calls c ugly "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-04 17:26 -0700
Re: this girl calls c ugly antispam@fricas.org (Waldek Hebisch) - 2026-06-05 12:58 +0000
Re: this girl calls c ugly "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-05 14:27 -0700
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-05 02:47 +0000
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-05 00:53 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-05 11:04 +0100
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-05 05:34 -0700
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-06 03:45 +0000
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-06 03:44 +0000
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-06 07:39 +0200
Re: this girl calls c ugly "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-04 15:25 -0700
Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-07-12 08:31 +0000
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-05 09:29 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-05 12:39 +0100
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-05 15:42 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-05 16:50 +0100
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-05 11:09 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-05 20:29 +0100
Re: this girl calls c ugly scott@slp53.sl.home (Scott Lurndal) - 2026-06-04 16:18 +0000
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-04 17:23 +0100
Re: this girl calls c ugly scott@slp53.sl.home (Scott Lurndal) - 2026-06-04 16:47 +0000
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-04 19:57 +0100
Re: this girl calls c ugly scott@slp53.sl.home (Scott Lurndal) - 2026-06-04 20:34 +0000
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-04 22:28 +0100
Re: this girl calls c ugly scott@slp53.sl.home (Scott Lurndal) - 2026-06-04 21:58 +0000
Re: this girl calls c ugly Richard Harnden <richard.nospam@gmail.invalid> - 2026-06-04 23:25 +0100
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-05 02:49 +0000
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-04 19:47 +0200
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-04 21:04 +0200
Re: this girl calls c ugly Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-06-04 19:13 +0000
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-05 10:34 +0200
Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-07-12 08:32 +0000
Re: this girl calls c ugly "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-07-12 11:05 -0700
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-04 12:11 -0700
Re: this girl calls c ugly James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-06-04 16:33 -0400
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-04 14:16 -0700
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-05 00:02 +0000
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-04 18:36 -0700
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-05 02:54 +0000
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-05 05:49 -0700
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-05 11:01 -0700
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-05 11:53 -0700
Re: this girl calls c ugly Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-06-04 18:45 +0000
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-04 20:19 +0000
Re: this girl calls c ugly scott@slp53.sl.home (Scott Lurndal) - 2026-06-04 20:31 +0000
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-04 20:41 +0000
Re: this girl calls c ugly scott@slp53.sl.home (Scott Lurndal) - 2026-06-04 20:49 +0000
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-05 00:03 +0000
Re: this girl calls c ugly scott@slp53.sl.home (Scott Lurndal) - 2026-06-05 00:18 +0000
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-05 03:02 +0000
Re: this girl calls c ugly scott@slp53.sl.home (Scott Lurndal) - 2026-06-05 14:04 +0000
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-06 03:49 +0000
Re: this girl calls c ugly scott@slp53.sl.home (Scott Lurndal) - 2026-06-06 15:13 +0000
Re: this girl calls c ugly scott@slp53.sl.home (Scott Lurndal) - 2026-06-06 17:53 +0000
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-04 11:59 -0700
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-04 15:21 +0200
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-04 06:38 -0700
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-01 09:52 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-01 02:42 -0700
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-01 12:50 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-01 11:47 +0100
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-01 12:55 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-01 14:39 -0700
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-01 15:11 -0700
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-02 08:41 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-02 02:07 -0700
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-02 11:38 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-02 05:01 -0700
It is not futile to change the subject line (Was: this girl calls c ugly) gazelle@shell.xmission.com (Kenny McCormack) - 2026-06-02 12:39 +0000
Re: It is not futile to change the subject line (Was: this girl calls c ugly) gazelle@shell.xmission.com (Kenny McCormack) - 2026-06-02 12:42 +0000
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-02 11:46 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-02 11:09 +0100
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-02 05:25 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-02 14:20 +0100
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-02 15:12 -0700
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-02 04:16 -0700
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-01 15:23 -0700
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-01 16:06 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-01 23:24 +0100
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-02 11:35 +0200
Operator precedence in other (non-C, but "C-like") languages (Was: something about a girl) gazelle@shell.xmission.com (Kenny McCormack) - 2026-06-02 12:36 +0000
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-01 11:04 +0000
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-01 14:04 +0200
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-01 18:48 +0000
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-01 21:04 +0100
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-02 09:17 +0200
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-02 09:09 +0200
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-02 12:07 +0000
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-02 14:37 +0200
Microcontroller software stacks (was Re: this girl calls c ugly) scott@slp53.sl.home (Scott Lurndal) - 2026-06-02 15:06 +0000
Re: Microcontroller software stacks (was Re: this girl calls c ugly) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-21 14:13 -0700
Re: Microcontroller software stacks (was Re: this girl calls c ugly) David Brown <david.brown@hesbynett.no> - 2026-06-22 08:58 +0200
Re: Microcontroller software stacks (was Re: this girl calls c ugly) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-22 03:35 -0700
Re: Microcontroller software stacks (was Re: this girl calls c ugly) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-22 10:50 +0000
Re: Microcontroller software stacks (was Re: this girl calls c ugly) David Brown <david.brown@hesbynett.no> - 2026-06-22 12:59 +0200
Storage needed when there are bit-field members Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-28 09:42 -0700
Re: Storage needed when there are bit-field members Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-28 18:06 -0700
Re: Storage needed when there are bit-field members Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-28 20:20 -0700
Re: Storage needed when there are bit-field members Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-14 14:56 -0700
Re: Storage needed when there are bit-field members scott@slp53.sl.home (Scott Lurndal) - 2026-08-14 22:30 +0000
Re: Storage needed when there are bit-field members Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-15 16:10 -0700
Re: Storage needed when there are bit-field members scott@slp53.sl.home (Scott Lurndal) - 2026-08-16 15:20 +0000
Re: Storage needed when there are bit-field members antispam@fricas.org (Waldek Hebisch) - 2026-08-19 19:34 +0000
Re: Storage needed when there are bit-field members Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-19 15:26 -0700
Re: Storage needed when there are bit-field members David Brown <david.brown@hesbynett.no> - 2026-08-20 11:00 +0200
Re: Storage needed when there are bit-field members Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-20 03:30 -0700
Re: Storage needed when there are bit-field members David Brown <david.brown@hesbynett.no> - 2026-08-20 13:58 +0200
Re: Storage needed when there are bit-field members Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-20 13:37 -0700
Re: Storage needed when there are bit-field members scott@slp53.sl.home (Scott Lurndal) - 2026-08-20 14:50 +0000
Re: Storage needed when there are bit-field members "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-20 12:31 -0700
Re: Storage needed when there are bit-field members antispam@fricas.org (Waldek Hebisch) - 2026-08-20 19:55 +0000
Re: Storage needed when there are bit-field members Michael S <already5chosen@yahoo.com> - 2026-08-20 22:15 +0300
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 12 of 24 — ← Prev page 1 … 10 11 [12] 13 14 … 24 Next page →
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-08-14 13:40 -0700 |
| Subject | Re: Expression statements (was Re: Meaning of "expression") |
| Message-ID | <86wlts5tbr.fsf@linuxsc.com> |
| In reply to | #400278 |
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:
>
> [...]
>
>>> For example, this program:
>>>
>>> #include <stdio.h>
>>> int main(void) {
>>> const int result = printf("%ld\n", 0.3);
>>> printf("printf returned %d\n", result);
>>> }
>>>
>>> on my system prints:
>>>
>>> 140732048673560
>>> printf returned 16
>>>
>>> gcc and clang warn about the format string. tcc doesn't.
>>>
>>> The (first) printf call was apparently successful because printf
>>> has no way to know that the argument was of an incorrect type
>>> (types don't really exist at run time).
>>
>> printf() could know if an argument were of an incorrect type, if
>> an implementation chose to do so.
>
> Sure. I did write "on my system", where printf has no way to know
> that the argument was of an incorrect type.
The "on my system" applies to what the program prints.
The paragraph that says "printf has no way to know" is a general
statement, for any implementation of printf(). If you had meant it
to apply only to your system, you should have said something like
"because that printf had no way to know". Without any qualifying
adjective or other indicator the statement is generic, not
specific.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-08-14 14:13 -0700 |
| Subject | Re: Expression statements (was Re: Meaning of "expression") |
| Message-ID | <115o0en$2rq0k$2@kst.eternal-september.org> |
| In reply to | #401180 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> [...]
>>
>>>> For example, this program:
>>>>
>>>> #include <stdio.h>
>>>> int main(void) {
>>>> const int result = printf("%ld\n", 0.3);
>>>> printf("printf returned %d\n", result);
>>>> }
>>>>
>>>> on my system prints:
>>>>
>>>> 140732048673560
>>>> printf returned 16
>>>>
>>>> gcc and clang warn about the format string. tcc doesn't.
>>>>
>>>> The (first) printf call was apparently successful because printf
>>>> has no way to know that the argument was of an incorrect type
>>>> (types don't really exist at run time).
>>>
>>> printf() could know if an argument were of an incorrect type, if
>>> an implementation chose to do so.
>>
>> Sure. I did write "on my system", where printf has no way to know
>> that the argument was of an incorrect type.
>
> The "on my system" applies to what the program prints.
>
> The paragraph that says "printf has no way to know" is a general
> statement, for any implementation of printf(). If you had meant it
> to apply only to your system, you should have said something like
> "because that printf had no way to know". Without any qualifying
> adjective or other indicator the statement is generic, not
> specific.
You're quibbling about something I wrote nearly two months ago.
Certainly printf has no way defined by the language to know whether
its arguments are of the correct types. An implementation could
provide that information via some system-specific method, but I know
of no implementations that do so, and I'd be surprised if any such
implementations exist. What I wrote was true on my system and is
very likely true on all real-world systems.
If you have something to say about whether any such implementations
exist, I invite you, but do not expect you, to share it. That might
actually be interesting.
--
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-08-19 08:32 -0700 |
| Subject | Re: Expression statements (was Re: Meaning of "expression") |
| Message-ID | <86ecfu15za.fsf@linuxsc.com> |
| In reply to | #401187 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>
>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>
>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>
>>> [...]
>>>
>>>>> For example, this program:
>>>>>
>>>>> #include <stdio.h>
>>>>> int main(void) {
>>>>> const int result = printf("%ld\n", 0.3);
>>>>> printf("printf returned %d\n", result);
>>>>> }
>>>>>
>>>>> on my system prints:
>>>>>
>>>>> 140732048673560
>>>>> printf returned 16
>>>>>
>>>>> gcc and clang warn about the format string. tcc doesn't.
>>>>>
>>>>> The (first) printf call was apparently successful because printf
>>>>> has no way to know that the argument was of an incorrect type
>>>>> (types don't really exist at run time).
>>>>
>>>> printf() could know if an argument were of an incorrect type, if
>>>> an implementation chose to do so.
>>>
>>> Sure. I did write "on my system", where printf has no way to know
>>> that the argument was of an incorrect type.
>>
>> The "on my system" applies to what the program prints.
>>
>> The paragraph that says "printf has no way to know" is a general
>> statement, for any implementation of printf(). If you had meant it
>> to apply only to your system, you should have said something like
>> "because that printf had no way to know". Without any qualifying
>> adjective or other indicator the statement is generic, not
>> specific.
>
> [...] Certainly printf has no way defined by the language to know
> whether its arguments are of the correct types. An implementation
> could provide that information via some system-specific method,
> [...]
I'm glad to know we are in agreement.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-08-19 15:09 -0700 |
| Subject | Re: Expression statements (was Re: Meaning of "expression") |
| Message-ID | <11659ir$314h2$1@kst.eternal-september.org> |
| In reply to | #401328 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
[...]
> I'm glad to know we are in agreement.
We're not.
--
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 | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2026-06-11 20:41 -0400 |
| Subject | Re: Expression statements (was Re: Meaning of "expression") |
| Message-ID | <110fkkd$1ltqe$1@dont-email.me> |
| In reply to | #399918 |
On 2026-06-11 18:37, Janis Papanagnou wrote:
> On 2026-06-11 21:13, James Kuyper wrote:
>> On 2026-06-11 14:12, Janis Papanagnou wrote:
>>> On 2026-06-10 00:34, Keith Thompson wrote:
>> ...
>>>> For I/O, the equivalent of printf is a procedure. In C,
>>>> printf("Hello, world\n") returns a negative result to denote an
>>>> error (and that value is often ignored).
>>>
>>> Erm, I hope that above printf() call does not create an error, but
>>> returns the number of characters in the printed text. ;-)
>>
>> Hope is nice. I hope, in particular, that you're aware that there are
>> not guarantees on that matter?
>
> Oh, actually I indeed thought that printing a constant string would not
> create any error that would then be indicated by printf's return value.
Every I/O function has a way of reporting failure, because every one is
capable of failing. That's because, if nothing else, hardware problems
could prevent I/O from happening. How much attention you need to pay to
that possibility depends upon the context.
> I'd indeed also expected that, say, printing a string value with a '%d'
> specifier would produce an error, but I saw that it doesn't; while the
> compiler creates just a warning, execution provides some random output
> and a _non-negative_ string-length value as printf's return value. Not
> exactly what I'd expect from a language.
On some systems I've used, it would try to interpret the pointer to the
string as an int, and print the result. On others, it would expect the
int to be stored in one register, whereas the pointer was stored in a
different register, and as a result it would print whatever value was
last stored in the first register. These were natural outcomes for those
implementations; had the C standard imposed any conflicting requirements
on the behavior, it would have complicated those implementations.
...
> Now of course an error can occur with that simple 'printf' above, for
> example, by issuing an 'fclose (stdout);' before the 'printf (...);'
> But what can I as a C-programmer derive from that; how would one act
> on that. (That's just rhetorical.)
>
> Obviously (because of that?) I've never seen anyone test such a call
> by, say,
>
> int rc = printf("Hello, world\n");
> if (rc < 0) {
> /* umm.. */
> }
>
> Are you - plural, all CLC audience - writing such code with 'printf()',
> honestly? - Same question with 'int rc = fclose (...);' - what can one
> do about that, then? (Write a logfile entry, maybe? - and then?)
For most of the programs I ever wrote, a single check for ferror(file)
at the end of the program, resulting in exit(EXIT_FAILURE) being called,
would be acceptable. That approach relies on the fact that the error
flag is sticky. Because I made a habit of such checks, we caught a
problem when a disk overflowed before we'd wasted hours "writing" data
to nowhere. If I had sent a message to a log file, it would have been
blocked by the same problem, which is why I used the exit status to
report the problem.
But I was never involved in writing interactive programs, where I
suspect that would not be acceptable.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-06-28 03:16 +0200 |
| Subject | Re: Expression statements (was Re: Meaning of "expression") |
| Message-ID | <111pskv$5rbc$2@dont-email.me> |
| In reply to | #399931 |
On 2026-06-12 02:41, James Kuyper wrote:
> On 2026-06-11 18:37, Janis Papanagnou wrote:
[...]
>> I'd indeed also expected that, say, printing a string value with a '%d'
>> specifier would produce an error, but I saw that it doesn't; while the
>> compiler creates just a warning, execution provides some random output
>> and a _non-negative_ string-length value as printf's return value. Not
>> exactly what I'd expect from a language.
>
> On some systems I've used, it would try to interpret the pointer to the
> string as an int, and print the result.
Right. That occurred to me only after I had sent my post.
> On others, it would expect the
> int to be stored in one register, whereas the pointer was stored in a
> different register, and as a result it would print whatever value was
> last stored in the first register. These were natural outcomes for those
> implementations; had the C standard imposed any conflicting requirements
> on the behavior, it would have complicated those implementations.
>> [...]
>>
>> Obviously (because of that?) I've never seen anyone test such a call
>> by, say,
>>
>> int rc = printf("Hello, world\n");
>> if (rc < 0) {
>> /* umm.. */
>> }
>>
>> Are you - plural, all CLC audience - writing such code with 'printf()',
>> honestly? - Same question with 'int rc = fclose (...);' - what can one
>> do about that, then? (Write a logfile entry, maybe? - and then?)
>
> For most of the programs I ever wrote, a single check for ferror(file)
> at the end of the program, resulting in exit(EXIT_FAILURE) being called,
> would be acceptable.
Hmm.. - I don't recall to have ever used ferror().
Personally it seems to me that continuing I/O once an error gets
flagged is not something I'd have done with an easy conscience.
So I'd not have dared to interrogate that state only once at the
end of the program. But then, instead of regularly calling ferror,
checking the RC should suffice?
(I think I mentioned already that usually we inspected the RC at
the place of generation for all functions where we felt it matters
and where we can act on such events.)
> That approach relies on the fact that the error
> flag is sticky. Because I made a habit of such checks, we caught a
> problem when a disk overflowed before we'd wasted hours "writing" data
> to nowhere. If I had sent a message to a log file, it would have been
> blocked by the same problem, which is why I used the exit status to
> report the problem.
Okay. In our cases we had no problems with disk overflows; our main
operational concern was communication of data, less storage of huge
amounts of temporaries or payload data. For logfiles we had our own
framework with IIRC a "tandem approach" (alternating between two or
more logfiles, each with a fixed maximum number of log-entries, and
reused when it's its turn); so disk space was well under control.
Janis
> [...]
[toc] | [prev] | [next] | [standalone]
| From | tTh <tth@none.invalid> |
|---|---|
| Date | 2026-06-09 19:27 +0200 |
| Subject | Re: Expression statements (was Re: Meaning of "expression") |
| Message-ID | <1109iem$1ton$1@news.gegeweb.eu> |
| In reply to | #399821 |
On 6/9/26 15:53, Bart wrote: > f() + g(); > > f() and g() both do something, but nothing is done with their sum. I've just one question : why did you waste your life time with a lot of non-sense questions ? -- ** ** * tTh des Bourtoulots * * http://maison.tth.netlib.re/ * ** **
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-06-09 19:19 +0100 |
| Subject | Re: Expression statements (was Re: Meaning of "expression") |
| Message-ID | <1109lep$75j3$1@dont-email.me> |
| In reply to | #399825 |
On 09/06/2026 18:27, tTh wrote: > On 6/9/26 15:53, Bart wrote: > >> f() + g(); >> >> f() and g() both do something, but nothing is done with their sum. > > I've just one question : why did you waste your life time > with a lot of non-sense questions ? > I didn't ask any question. You, on the other hand, did. I take it that you don't understand what is being discussed, and why. In that case you're wasting /your/ time posting.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-06-09 15:22 -0700 |
| Subject | Re: Expression statements (was Re: Meaning of "expression") |
| Message-ID | <110a3me$b2kq$3@kst.eternal-september.org> |
| In reply to | #399820 |
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
[...]
> Above you used the term "expression statement", and then compare the
> "42" to an "expression".
>
> I know from my earlier C-days that '42;' is a valid statement, and so
> the term "expression statement" makes sense to me.
Sorry, I thought that would be clear enough.
Syntactically, an expression-statement is an optional statement
followed by a semicolon (N3220 6.8.4, glossing over an irrelevant
detail). I merely used it as an easy way to establish a context in
which 42 is obviously a full expression (defined as "an expression
that is not part of another expression, nor part of a declarator
or abstract declarator").
An expression-statement where the expression has no side effects
is not useful, but it's permitted. C tends not to ban things just
because they're not useful. `42;` is useful only to illustrate
the point I was making about expressions.
Since a function call is an expression, this is an expression-statement:
printf("hello, world\n");
[...]
To be clear, I have zero doubt that 42 is an expression. My concern
is that the C standard's English definition of "expression" doesn't
quite say so. I advocate improving the wording so it expresses
the obvious and universally agreed intent.
--
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-08-15 00:42 -0700 |
| Subject | Re: Meaning of "expression" |
| Message-ID | <86jypr6d96.fsf@linuxsc.com> |
| In reply to | #399799 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > [...] > >> The actual text of the standard implies that 42 is not an >> expression. I rely on the obvious intent to conclude that it is. > > I made the above statement to demonstrate that just following the > exact wording of the standard, without thinking about the (sometimes > unclear) intent behind it, can lead to absurd results. > > I've discussed this particular glitch before, but it's been a while. > > N3220 6.5.1 says: > > An *expression* is a sequence of operators and operands that > specifies computation of a value, or that designates an object > or a function, or that generates side effects, or that performs > a combination thereof. > > I believe the wording is unchanged from C90 up to the latest C202y > draft. Since the word "expression" is in italics, this is the > standard's definition of the word. > > This is a flawed definition. The terms "operator" and "operand" > are defined in 6.4.6: > > *punctuator: one of > [ ] ( ) > [snip] > > A punctuator is a symbol that has independent syntactic and > semantic significance. Depending on context, it may specify an > operation to be performed (which in turn may yield a value or a > function designator, produce a side effect, or some combination > thereof) in which case it is known as an *operator* (other forms > of operator also exist in some contexts). An *operand* is an > entity on which an operator acts. > > Consider this expression statement: > > 42; > > Is `42` an expression? Clearly it's intended to be, but there is no > operator, and therefore there is no operand, so it doesn't meet the > standard's definition of the word "expression". I think this conclusion can be explained as a misreading of the text in the C standard. In reading the text "An *expression* is a sequence of operators and operands", I think you are interpreting it as meaning "at least one of each of operators and operands". But this text could also be read as "at least one of either of operators and operands", or in other words a sequence of elements of the set containing both operands and operators, in which case 42 would qualify as an expression. An argument might be made about whether the text in the C standard _should_ mean that, but certainly it _could_ mean that.
[toc] | [prev] | [next] | [standalone]
| From | Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> |
|---|---|
| Date | 2026-08-15 19:42 +0800 |
| Subject | The meaning of 42 ; (was: Re: Meaning of "expression") |
| Message-ID | <TgYfS.340664$KyJ1.128902@fx13.ams4> |
| In reply to | #401201 |
On 15/08/2026 3:42 PM, Tim Rentsch wrote:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> [...]
>>
>>> The actual text of the standard implies that 42 is not an
>>> expression. I rely on the obvious intent to conclude that it is.
>>
>> I made the above statement to demonstrate that just following the
>> exact wording of the standard, without thinking about the (sometimes
>> unclear) intent behind it, can lead to absurd results.
>>
>> I've discussed this particular glitch before, but it's been a while.
>>
>> N3220 6.5.1 says:
>>
>> An *expression* is a sequence of operators and operands that
>> specifies computation of a value, or that designates an object
>> or a function, or that generates side effects, or that performs
>> a combination thereof.
>>
>> I believe the wording is unchanged from C90 up to the latest C202y
>> draft. Since the word "expression" is in italics, this is the
>> standard's definition of the word.
>>
>> This is a flawed definition. The terms "operator" and "operand"
>> are defined in 6.4.6:
>>
>> *punctuator: one of
>> [ ] ( )
>> [snip]
>>
>> A punctuator is a symbol that has independent syntactic and
>> semantic significance. Depending on context, it may specify an
>> operation to be performed (which in turn may yield a value or a
>> function designator, produce a side effect, or some combination
>> thereof) in which case it is known as an *operator* (other forms
>> of operator also exist in some contexts). An *operand* is an
>> entity on which an operator acts.
>>
>> Consider this expression statement:
>>
>> 42;
>>
>> Is `42` an expression? Clearly it's intended to be, but there is no
>> operator, and therefore there is no operand, so it doesn't meet the
>> standard's definition of the word "expression".
>
> I think this conclusion can be explained as a misreading of the text
> in the C standard. In reading the text "An *expression* is a
> sequence of operators and operands", I think you are interpreting it
> as meaning "at least one of each of operators and operands". But
> this text could also be read as "at least one of either of operators
> and operands", or in other words a sequence of elements of the set
> containing both operands and operators, in which case 42 would
> qualify as an expression.
>
> An argument might be made about whether the text in the C standard
> _should_ mean that, but certainly it _could_ mean that.
My compiler accepts
int main( int argc, char *argv[] ) {
42 ;
return 0 ;
}
and builds an executable out of it. Does yours?
--
Johann | email: invalid -> com | http://www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | via Easynews.com
https://bsky.app/profile/myrkraverk.bsky.social | for ( ;; ) _:;
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-08-15 05:36 -0700 |
| Subject | Re: Meaning of "expression" |
| Message-ID | <115pmgh$3c96f$1@kst.eternal-september.org> |
| In reply to | #401201 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> [...]
>>
>>> The actual text of the standard implies that 42 is not an
>>> expression. I rely on the obvious intent to conclude that it is.
>>
>> I made the above statement to demonstrate that just following the
>> exact wording of the standard, without thinking about the (sometimes
>> unclear) intent behind it, can lead to absurd results.
>>
>> I've discussed this particular glitch before, but it's been a while.
>>
>> N3220 6.5.1 says:
>>
>> An *expression* is a sequence of operators and operands that
>> specifies computation of a value, or that designates an object
>> or a function, or that generates side effects, or that performs
>> a combination thereof.
>>
>> I believe the wording is unchanged from C90 up to the latest C202y
>> draft. Since the word "expression" is in italics, this is the
>> standard's definition of the word.
>>
>> This is a flawed definition. The terms "operator" and "operand"
>> are defined in 6.4.6:
>>
>> *punctuator: one of
>> [ ] ( )
>> [snip]
>>
>> A punctuator is a symbol that has independent syntactic and
>> semantic significance. Depending on context, it may specify an
>> operation to be performed (which in turn may yield a value or a
>> function designator, produce a side effect, or some combination
>> thereof) in which case it is known as an *operator* (other forms
>> of operator also exist in some contexts). An *operand* is an
>> entity on which an operator acts.
>>
>> Consider this expression statement:
>>
>> 42;
>>
>> Is `42` an expression? Clearly it's intended to be, but there is no
>> operator, and therefore there is no operand, so it doesn't meet the
>> standard's definition of the word "expression".
>
> I think this conclusion can be explained as a misreading of the text
> in the C standard. In reading the text "An *expression* is a
> sequence of operators and operands", I think you are interpreting it
> as meaning "at least one of each of operators and operands". But
> this text could also be read as "at least one of either of operators
> and operands", or in other words a sequence of elements of the set
> containing both operands and operators, in which case 42 would
> qualify as an expression.
No. The term "operand" is defined in N3220 6.4.6p2:
An *operand* is an entity on which an operator acts.
As I already explained, in the expression statement `42;`, 42 it is
neither an operator nor an operand. It can't be an operand unless
there's an operator to act on it. So your reading of the text as
"at least one of either of operators and operands" doesn't help.
> An argument might be made about whether the text in the C standard
> _should_ mean that, but certainly it _could_ mean that.
It might be reasonable to define "operand" in a way that includes
a constant that is a full expression, but the standard clearly
doesn't say that.
To restate the obvious, my argument is not that `42` is not an
expression. It's that the standard's definition of "expression"
is flawed. The only sensible workaround is to pretend that `42`
is an expression -- basically to ignore the italicized definition of
"expression" and instead rely on the grammar production.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-06-06 03:22 +0000 |
| Message-ID | <11003or$t9b$1@reader1.panix.com> |
| In reply to | #399748 |
In article <86bjdpayv0.fsf@linuxsc.com>, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: >> [snip] >> But taking a closer look at the standard, I'm not 100% sure that the >> language requires a diagnostic, though I think that's the intent. >> The relevant constraint is: >> >> Each constant expression shall evaluate to a constant that is >> in the range of representable values for its type. >> >> If I squint really hard, I can argue that the entire expression >> has to be a constant expression, but it doesn't say that its >> subexpressions are constant expressions -- and *if* INT_MAX + >> 1 evaluates to INT_MIN in the current implementation, then >> (INT_MAX + 1) * 0 evaluates to 0 and therefore satisfies the >> constraint. > >My reasoning is as follows. > >To determine if the constraint is satisfied, the compiler must >first evaluate the expression (INT_MAX + 1) * 0. > >To evaluate the expression (INT_MAX + 1) * 0, the compiler must >first evaluate the sub-expression (INT_MAX + 1). > >Because the expression (INT_MAX + 1) overflows, the behavior is >undefined, and the compiler is free to decide that the value of >the sub-expression (INT_MAX + 1) is, let's say, 12. > >The compiler next evaluates the overall expression as 12*0, which >is 0 (an int). > >This result of the overall expression satisfies the constraint, >and so the compiler is not obliged to generate a diagnostic. The text of the standard explicitly carves this out; or, rather, it attempts to. If the result of an expression is not representable in the target type, _regardless of whether that's due to UB or not_, a diagnostic is required. But as it happens, I think I can see how your interpretation may be valid: if, as a result of UB, the expression evaluates to "0" (or 12 or something simiilar) that _is_ representable, then there _is no constraint violation_ and so no diagnostic is required. I do not believe that that is the intent. But it _is_ conformant with the text of the standard. This is a problem with the C standard: it is insufficiently precise, as the semantics of the language are not formally defined. >[snip] >I see no basis for this belief. My conclusions are based on what >the C standard actually says, rather than guesses about some >unstated "intentions". I think you would do well to reach your >conclusions based more on the actual text of the C standard, and >less on your interpretation of what the text was "intended" to >mean. The same could be said to you, as well. There exists a reading of the standard by which your `foo`-containing program is not strictly conforming . But that way lies madness; C is not a formally specified language. Given that as an objective fact, we must accept intent, consistency, and other "soft" aspects when considering its definition. That sort of sucks, but here we are. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-06-05 23:56 -0700 |
| Message-ID | <1100gbk$1lt8i$2@kst.eternal-september.org> |
| In reply to | #399761 |
cross@spitfire.i.gajendra.net (Dan Cross) writes:
[...]
> The text of the standard explicitly carves this out; or, rather,
> it attempts to. If the result of an expression is not
> representable in the target type, _regardless of whether that's
> due to UB or not_, a diagnostic is required.
[...]
How would an expression (appearing in a context that requires an
integer constant expression) not "evaluate to a constant that is in
the range of representable values for its type" other than by UB?
I can't think of an example, but I'd be interested in seeing one.
Note in particular that UINT_MAX+1U is well defined, not an overflow.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-06-07 13:37 +0000 |
| Message-ID | <1103s6v$78r$1@reader1.panix.com> |
| In reply to | #399767 |
In article <1100gbk$1lt8i$2@kst.eternal-september.org>, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: >cross@spitfire.i.gajendra.net (Dan Cross) writes: >[...] >> The text of the standard explicitly carves this out; or, rather, >> it attempts to. If the result of an expression is not >> representable in the target type, _regardless of whether that's >> due to UB or not_, a diagnostic is required. >[...] > >How would an expression (appearing in a context that requires an >integer constant expression) not "evaluate to a constant that is in >the range of representable values for its type" other than by UB? It wouldn't. But because it's UB, it could evaluate to anything, including something that didn't violate the constraint. >I can't think of an example, but I'd be interested in seeing one. In terms of a practical, working compiler? I doubt that one exists. >Note in particular that UINT_MAX+1U is well defined, not an overflow. Yes. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-06-07 15:09 -0700 |
| Message-ID | <1104q77$2qkh5$1@kst.eternal-september.org> |
| In reply to | #399783 |
cross@spitfire.i.gajendra.net (Dan Cross) writes:
> In article <1100gbk$1lt8i$2@kst.eternal-september.org>,
> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>cross@spitfire.i.gajendra.net (Dan Cross) writes:
>>[...]
>>> The text of the standard explicitly carves this out; or, rather,
>>> it attempts to. If the result of an expression is not
>>> representable in the target type, _regardless of whether that's
>>> due to UB or not_, a diagnostic is required.
>>[...]
>>
>>How would an expression (appearing in a context that requires an
>>integer constant expression) not "evaluate to a constant that is in
>>the range of representable values for its type" other than by UB?
>
> It wouldn't. But because it's UB, it could evaluate to
> anything, including something that didn't violate the
> constraint.
>
>>I can't think of an example, but I'd be interested in seeing one.
>
> In terms of a practical, working compiler? I doubt that one
> exists.
I actually meant in terms of the standard, not of any particular
compiler.
I can't think of an example, but maybe someone else can.
[...]
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-06-08 02:33 +0000 |
| Message-ID | <11059mm$mv5$2@reader1.panix.com> |
| In reply to | #399784 |
In article <1104q77$2qkh5$1@kst.eternal-september.org>, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: >cross@spitfire.i.gajendra.net (Dan Cross) writes: >> In article <1100gbk$1lt8i$2@kst.eternal-september.org>, >> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: >>>cross@spitfire.i.gajendra.net (Dan Cross) writes: >>>[...] >>>> The text of the standard explicitly carves this out; or, rather, >>>> it attempts to. If the result of an expression is not >>>> representable in the target type, _regardless of whether that's >>>> due to UB or not_, a diagnostic is required. >>>[...] >>> >>>How would an expression (appearing in a context that requires an >>>integer constant expression) not "evaluate to a constant that is in >>>the range of representable values for its type" other than by UB? >> >> It wouldn't. But because it's UB, it could evaluate to >> anything, including something that didn't violate the >> constraint. >> >>>I can't think of an example, but I'd be interested in seeing one. >> >> In terms of a practical, working compiler? I doubt that one >> exists. > >I actually meant in terms of the standard, not of any particular >compiler. > >I can't think of an example, but maybe someone else can. > >[...] Oh. Well, I suppose something that relied on _IB_, like conversion from a large unsigned integer type to a smaller signed integer type that led to a trap, might fall into that category. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-08-15 09:37 -0700 |
| Message-ID | <86tsov49wj.fsf@linuxsc.com> |
| In reply to | #399767 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > cross@spitfire.i.gajendra.net (Dan Cross) writes: > [...] > >> The text of the standard explicitly carves this out; or, rather, >> it attempts to. If the result of an expression is not >> representable in the target type, _regardless of whether that's >> due to UB or not_, a diagnostic is required. > > [...] > > How would an expression (appearing in a context that requires an > integer constant expression) not "evaluate to a constant that is in > the range of representable values for its type" other than by UB? I can think of one.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-08-15 17:29 -0700 |
| Message-ID | <115r09e$3qb10$1@kst.eternal-september.org> |
| In reply to | #401213 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>
>> cross@spitfire.i.gajendra.net (Dan Cross) writes:
>> [...]
>>
>>> The text of the standard explicitly carves this out; or, rather,
>>> it attempts to. If the result of an expression is not
>>> representable in the target type, _regardless of whether that's
>>> due to UB or not_, a diagnostic is required.
>>
>> [...]
>>
>> How would an expression (appearing in a context that requires an
>> integer constant expression) not "evaluate to a constant that is in
>> the range of representable values for its type" other than by UB?
>
> I can think of one.
So you've decided to be a troll.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-08-18 20:30 +0000 |
| Message-ID | <1162fd1$lvu$1@reader1.panix.com> |
| In reply to | #401226 |
In article <115r09e$3qb10$1@kst.eternal-september.org>, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: >Tim Rentsch <tr.17687@z991.linuxsc.com> writes: >> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: >> >>> cross@spitfire.i.gajendra.net (Dan Cross) writes: >>> [...] >>> >>>> The text of the standard explicitly carves this out; or, rather, >>>> it attempts to. If the result of an expression is not >>>> representable in the target type, _regardless of whether that's >>>> due to UB or not_, a diagnostic is required. >>> >>> [...] >>> >>> How would an expression (appearing in a context that requires an >>> integer constant expression) not "evaluate to a constant that is in >>> the range of representable values for its type" other than by UB? >> >> I can think of one. > >So you've decided to be a troll. I think it's been that way for a while, sadly. His MO seems to be to make a claim, be shown to be wrong, disappear for an extended stretch, and then reappear with a non-response. - Dan C.
[toc] | [prev] | [next] | [standalone]
Page 12 of 24 — ← Prev page 1 … 10 11 [12] 13 14 … 24 Next page →
Back to top | Article view | comp.lang.c
csiph-web