Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #399456 > unrolled thread
| Started by | fir <profesor.fir@gmail.com> |
|---|---|
| First post | 2026-05-27 19:53 +0200 |
| Last post | 2026-05-30 11:18 +0200 |
| Articles | 20 on this page of 448 — 24 participants |
Back to article view | Back to comp.lang.c
this girl calls c ugly fir <profesor.fir@gmail.com> - 2026-05-27 19:53 +0200
Re: this girl calls c ugly fir <profesor.fir@gmail.com> - 2026-05-27 20:15 +0200
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-27 18:49 -0500
Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-28 04:53 +0000
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-28 02:35 -0500
Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-28 23:32 +0000
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-28 20:07 -0500
Re: this girl calls c ugly Bonita Montero <Bonita.Montero@gmail.com> - 2026-05-28 11:48 +0200
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-28 09:18 +0200
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-28 04:57 -0500
Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-28 23:35 +0000
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 09:52 +0200
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-29 05:20 -0500
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-29 13:22 +0200
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-29 15:16 -0500
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-30 13:52 +0200
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-30 14:40 +0200
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-30 16:36 +0200
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-30 15:48 -0500
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-31 11:14 +0200
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-31 13:25 -0500
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-31 22:14 +0200
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 15:22 +0200
Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-30 03:49 +0000
Re: this girl calls c ugly "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-05-28 12:47 -0700
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 09:56 +0200
Re: this girl calls c ugly "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-05-29 11:00 -0700
Re: this girl calls c ugly fir <profesor.fir@gmail.com> - 2026-05-28 17:12 +0200
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-28 14:07 -0500
Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-28 23:54 +0000
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 10:02 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 12:19 +0100
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 14:46 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 14:22 +0100
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 17:15 +0200
Re: this girl calls c ugly scott@slp53.sl.home (Scott Lurndal) - 2026-05-29 15:59 +0000
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 17:12 +0100
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 18:48 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 19:09 +0100
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 22:00 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 22:14 +0100
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-29 12:09 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 17:05 +0100
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 18:34 +0200
Re: this girl calls c ugly tTh <tth@none.invalid> - 2026-05-29 19:29 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 18:53 +0100
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-29 12:28 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 20:49 +0100
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 22:03 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-29 13:56 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 22:54 +0100
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-29 15:52 -0700
Re: this girl calls c ugly James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-05-29 20:31 -0400
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-30 02:03 +0100
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-29 19:02 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-30 12:12 +0100
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-30 12:29 +0000
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-30 13:56 +0100
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-30 16:43 -0700
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-31 03:37 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-30 19:53 -0700
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-02 12:16 +0200
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-31 11:47 +0200
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-02 12:55 +0200
Re: this girl calls c ugly Richard Harnden <richard.nospam@gmail.invalid> - 2026-05-31 09:12 +0100
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-31 11:49 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-31 11:10 +0100
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-31 13:18 +0200
Re: this girl calls c ugly James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-05-31 10:24 -0400
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-31 17:35 +0200
Re: this girl calls c ugly James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-05-31 12:46 -0400
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-31 22:24 +0200
Re: this girl calls c ugly James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-05-31 18:26 -0400
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-01 08:28 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-31 15:54 -0700
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-01 08:39 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-01 02:33 -0700
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-02 11:48 +0200
Re: this girl calls c ugly James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-06-02 06:37 -0400
Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-02 05:06 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-02 16:28 +0000
Re: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-04 03:37 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-04 16:31 +0000
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-04 13:36 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-04 23:49 +0000
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-04 18:04 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-06 03:10 +0000
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-05 23:50 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-08 02:20 +0000
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-08 12:39 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-08 23:15 +0000
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-08 18:51 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-09 09:46 +0000
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-09 15:07 -0700
Re: Constants and undefined behavior antispam@fricas.org (Waldek Hebisch) - 2026-06-09 01:25 +0000
Re: Constants and undefined behavior James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-06-09 18:29 -0400
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-09 16:01 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-10 12:36 +0000
Re: Constants and undefined behavior Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-11 16:49 +0200
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-11 15:20 +0000
Re: Constants and undefined behavior Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-11 18:08 +0200
Re: Constants and undefined behavior antispam@fricas.org (Waldek Hebisch) - 2026-06-11 16:30 +0000
Re: Constants and undefined behavior Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-11 20:52 +0200
Re: Constants and undefined behavior antispam@fricas.org (Waldek Hebisch) - 2026-06-12 02:20 +0000
Re: Constants and undefined behavior Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-13 14:57 +0200
Re: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-21 15:26 -0700
Re: Constants and undefined behavior antispam@fricas.org (Waldek Hebisch) - 2026-06-22 03:40 +0000
Re: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-15 07:50 -0700
Re: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-21 14:26 -0700
Re: Constants and undefined behavior antispam@fricas.org (Waldek Hebisch) - 2026-06-22 03:56 +0000
Re: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-29 06:27 -0700
Re: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-06 15:47 -0700
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-06 16:36 -0700
Re: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-06 16:43 -0700
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-06 17:41 -0700
Re: Constants and undefined behavior Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-05 10:41 +0200
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-05 10:49 -0700
Re: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-06 16:15 -0700
Re: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-06 18:06 -0700
Re: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-07 22:34 -0700
Re: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-08 23:05 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-09 10:19 +0000
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-09 15:12 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-10 14:37 +0000
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-10 18:30 +0000
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-10 14:55 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-10 23:32 +0000
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-10 14:47 -0700
Re: Constants and undefined behavior David Brown <david.brown@hesbynett.no> - 2026-06-11 08:56 +0200
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-11 11:38 +0000
Re: Constants and undefined behavior David Brown <david.brown@hesbynett.no> - 2026-06-11 14:05 +0200
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-11 15:38 -0700
Re: Constants and undefined behavior scott@slp53.sl.home (Scott Lurndal) - 2026-06-11 23:07 +0000
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-11 17:43 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-12 02:02 +0000
Re: Constants and undefined behavior Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-11 17:34 +0200
Re: Constants and undefined behavior David Brown <david.brown@hesbynett.no> - 2026-06-12 10:58 +0200
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-12 12:27 -0700
Re: Constants and undefined behavior David Brown <david.brown@hesbynett.no> - 2026-06-13 12:36 +0200
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-13 12:03 +0000
Re: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-14 12:35 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-13 12:02 +0000
Re: Constants and undefined behavior ram@zedat.fu-berlin.de (Stefan Ram) - 2026-06-13 12:13 +0000
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-13 12:44 +0000
Re: Constants and undefined behavior ram@zedat.fu-berlin.de (Stefan Ram) - 2026-06-14 17:22 +0000
Re: Constants and undefined behavior scott@slp53.sl.home (Scott Lurndal) - 2026-06-14 21:24 +0000
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-15 17:52 +0000
Re: Constants and undefined behavior David Brown <david.brown@hesbynett.no> - 2026-06-13 18:32 +0200
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-14 14:33 +0000
Re: Constants and undefined behavior David Brown <david.brown@hesbynett.no> - 2026-06-14 22:02 +0200
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-14 15:55 -0700
Re: Constants and undefined behavior David Brown <david.brown@hesbynett.no> - 2026-06-15 10:09 +0200
Re: Constants and undefined behavior antispam@fricas.org (Waldek Hebisch) - 2026-06-15 10:43 +0000
Re: Constants and undefined behavior David Brown <david.brown@hesbynett.no> - 2026-06-15 16:01 +0200
Re: Constants and undefined behavior antispam@fricas.org (Waldek Hebisch) - 2026-06-15 17:57 +0000
Re: Constants and undefined behavior David Brown <david.brown@hesbynett.no> - 2026-06-16 10:10 +0200
Re: Constants and undefined behavior Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-24 17:45 +0200
Re: Constants and undefined behavior "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-24 12:27 -0700
Re: Constants and undefined behavior Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-24 16:58 +0200
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-15 19:26 +0000
Re: Constants and undefined behavior James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-06-15 21:59 -0400
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-16 04:59 +0000
Re: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-29 05:41 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-29 15:23 +0000
Re: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-15 07:36 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-08-18 20:27 +0000
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-11 13:29 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-12 02:08 +0000
Re: Constants and undefined behavior David Brown <david.brown@hesbynett.no> - 2026-06-12 11:02 +0200
Re: Constants and undefined behavior Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-11 17:45 +0200
Re: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-10 15:11 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-10 22:44 +0000
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-10 16:19 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-11 11:50 +0000
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-11 16:28 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-11 23:46 +0000
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-11 18:29 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-12 01:54 +0000
Re: Constants and undefined behavior David Brown <david.brown@hesbynett.no> - 2026-06-12 11:37 +0200
Re: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-15 07:58 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-08-18 20:28 +0000
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-02 05:35 -0700
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-02 06:29 -0700
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-02 16:10 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-02 15:29 -0700
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-05 06:41 -0700
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-05 11:24 -0700
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-08 08:35 -0700
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-08 17:33 +0000
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-09 00:54 -0700
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-09 10:08 +0000
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-08 13:40 -0700
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-15 09:37 -0700
Meaning of "expression" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-08 14:05 -0700
Expression statements (was Re: Meaning of "expression") Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-09 15:17 +0200
Re: Expression statements (was Re: Meaning of "expression") Bart <bc@freeuk.com> - 2026-06-09 14:53 +0100
Re: Expression statements (was Re: Meaning of "expression") Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-09 16:30 +0200
Re: Expression statements (was Re: Meaning of "expression") David Brown <david.brown@hesbynett.no> - 2026-06-09 17:13 +0200
Re: Expression statements (was Re: Meaning of "expression") Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-09 15:34 -0700
Re: Expression statements (was Re: Meaning of "expression") David Brown <david.brown@hesbynett.no> - 2026-06-10 09:04 +0200
Re: Expression statements (was Re: Meaning of "expression") Bart <bc@freeuk.com> - 2026-06-10 11:10 +0100
Re: Expression statements (was Re: Meaning of "expression") David Brown <david.brown@hesbynett.no> - 2026-06-10 13:29 +0200
Re: Expression statements (was Re: Meaning of "expression") Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-10 03:17 -0700
Re: Expression statements (was Re: Meaning of "expression") David Brown <david.brown@hesbynett.no> - 2026-06-10 13:43 +0200
Re: Expression statements (was Re: Meaning of "expression") Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-10 14:08 -0700
Re: Expression statements (was Re: Meaning of "expression") David Brown <david.brown@hesbynett.no> - 2026-06-11 09:10 +0200
Re: Expression statements (was Re: Meaning of "expression") Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-11 20:29 +0200
Re: Expression statements (was Re: Meaning of "expression") David Brown <david.brown@hesbynett.no> - 2026-06-12 12:55 +0200
Re: Expression statements (was Re: Meaning of "expression") Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-13 15:01 +0200
Re: Expression statements (was Re: Meaning of "expression") Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-11 20:12 +0200
Re: Expression statements (was Re: Meaning of "expression") James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-06-11 15:13 -0400
Re: Expression statements (was Re: Meaning of "expression") Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-12 00:37 +0200
Re: Expression statements (was Re: Meaning of "expression") scott@slp53.sl.home (Scott Lurndal) - 2026-06-11 23:05 +0000
Re: Expression statements (was Re: Meaning of "expression") Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-12 01:18 +0200
Re: Expression statements (was Re: Meaning of "expression") Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-11 17:41 -0700
Re: Expression statements (was Re: Meaning of "expression") Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-28 02:49 +0200
Re: Expression statements (was Re: Meaning of "expression") Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-27 21:00 -0700
Re: Expression statements (was Re: Meaning of "expression") Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-28 09:52 -0700
Re: Expression statements (was Re: Meaning of "expression") Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-28 18:28 -0700
Re: Expression statements (was Re: Meaning of "expression") Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-14 13:40 -0700
Re: Expression statements (was Re: Meaning of "expression") Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-14 14:13 -0700
Re: Expression statements (was Re: Meaning of "expression") James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-06-11 20:41 -0400
Re: Expression statements (was Re: Meaning of "expression") Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-28 03:16 +0200
Re: Expression statements (was Re: Meaning of "expression") tTh <tth@none.invalid> - 2026-06-09 19:27 +0200
Re: Expression statements (was Re: Meaning of "expression") Bart <bc@freeuk.com> - 2026-06-09 19:19 +0100
Re: Expression statements (was Re: Meaning of "expression") Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-09 15:22 -0700
Re: Meaning of "expression" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-15 00:42 -0700
The meaning of 42 ; (was: Re: Meaning of "expression") Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-15 19:42 +0800
Re: Meaning of "expression" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-15 05:36 -0700
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-06 03:22 +0000
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-05 23:56 -0700
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-07 13:37 +0000
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-07 15:09 -0700
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-08 02:33 +0000
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-15 09:37 -0700
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-15 17:29 -0700
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-08-18 20:30 +0000
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-08 00:16 -0700
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-08 12:41 +0000
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-08 17:37 +0000
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-09 16:05 +0200
Re: this girl calls c ugly "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-02 13:59 -0700
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-02 13:05 +0000
Parentheses (was: this girl calls c ugly) Bart <bc@freeuk.com> - 2026-06-02 14:38 +0100
Re: Parentheses (was: this girl calls c ugly) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-02 15:19 +0000
Re: Parentheses antispam@fricas.org (Waldek Hebisch) - 2026-06-03 22:30 +0000
Re: Parentheses Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-03 16:24 -0700
Re: Parentheses antispam@fricas.org (Waldek Hebisch) - 2026-06-04 02:03 +0000
Re: Parentheses Bart <bc@freeuk.com> - 2026-06-04 01:12 +0100
Re: Parentheses antispam@fricas.org (Waldek Hebisch) - 2026-06-04 01:58 +0000
Re: Parentheses Bart <bc@freeuk.com> - 2026-06-04 11:37 +0100
Re: Parentheses cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-04 10:51 +0000
Re: Parentheses Bart <bc@freeuk.com> - 2026-06-04 12:47 +0100
Re: Parentheses Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-04 14:57 +0200
Re: Parentheses cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-04 14:31 +0000
[OT] Fancy graphics (was Re: this girl calls c ugly) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-02 15:54 +0200
Re: [OT] Fancy graphics (was Re: this girl calls c ugly) Bart <bc@freeuk.com> - 2026-06-02 15:19 +0100
Re: [OT] Fancy graphics (was Re: this girl calls c ugly) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-02 15:19 +0000
Re: [OT] Fancy graphics (was Re: this girl calls c ugly) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-02 17:39 +0200
Re: [OT] Fancy graphics (was Re: this girl calls c ugly) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-02 16:36 +0000
Re: [OT] Fancy graphics (was Re: this girl calls c ugly) scott@slp53.sl.home (Scott Lurndal) - 2026-06-02 21:33 +0000
Re: [OT] Fancy graphics (was Re: this girl calls c ugly) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-02 14:43 -0700
Re: [OT] Fancy graphics (was Re: this girl calls c ugly) ram@zedat.fu-berlin.de (Stefan Ram) - 2026-06-02 17:08 +0000
Re: [OT] Fancy graphics (was Re: this girl calls c ugly) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-02 19:19 +0000
Re: [OT] Fancy graphics (was Re: this girl calls c ugly) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-04 00:11 +0000
Re: [OT] Fancy graphics (was Re: this girl calls c ugly) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-02 15:39 -0700
Re: [OT] Fancy graphics (was Re: this girl calls c ugly) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-03 13:14 +0000
Re: this girl calls c ugly scott@slp53.sl.home (Scott Lurndal) - 2026-06-02 15:10 +0000
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-02 15:31 +0000
Re: this girl calls c ugly James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-05-31 10:15 -0400
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-31 16:29 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-31 03:45 -0700
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-31 04:02 -0700
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-31 09:04 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-31 18:11 +0100
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-31 19:34 +0000
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-31 19:10 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-01 11:12 +0100
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-01 12:36 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-01 14:26 -0700
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-04 02:34 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-04 12:40 +0100
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-04 14:35 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-04 14:18 +0100
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-04 15:47 +0200
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-04 15:57 +0200
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-04 16:27 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-04 16:46 +0100
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-04 20:15 +0200
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-04 20:54 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-04 20:29 +0100
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-04 14:06 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-04 22:47 +0100
Famous (hopefully last) words [on this topic] Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-05 00:27 +0200
Re: Famous (hopefully last) words [on this topic] Bad Post <invalid@invalid.invalid> - 2026-06-05 01:20 +0100
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-04 16:09 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-05 00:44 +0100
Re: this girl calls c ugly "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-04 17:26 -0700
Re: this girl calls c ugly antispam@fricas.org (Waldek Hebisch) - 2026-06-05 12:58 +0000
Re: this girl calls c ugly "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-05 14:27 -0700
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-05 02:47 +0000
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-05 00:53 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-05 11:04 +0100
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-05 05:34 -0700
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-06 03:45 +0000
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-06 03:44 +0000
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-06 07:39 +0200
Re: this girl calls c ugly "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-04 15:25 -0700
Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-07-12 08:31 +0000
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-05 09:29 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-05 12:39 +0100
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-05 15:42 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-05 16:50 +0100
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-05 11:09 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-05 20:29 +0100
Re: this girl calls c ugly scott@slp53.sl.home (Scott Lurndal) - 2026-06-04 16:18 +0000
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-04 17:23 +0100
Re: this girl calls c ugly scott@slp53.sl.home (Scott Lurndal) - 2026-06-04 16:47 +0000
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-04 19:57 +0100
Re: this girl calls c ugly scott@slp53.sl.home (Scott Lurndal) - 2026-06-04 20:34 +0000
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-04 22:28 +0100
Re: this girl calls c ugly scott@slp53.sl.home (Scott Lurndal) - 2026-06-04 21:58 +0000
Re: this girl calls c ugly Richard Harnden <richard.nospam@gmail.invalid> - 2026-06-04 23:25 +0100
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-05 02:49 +0000
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-04 19:47 +0200
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-04 21:04 +0200
Re: this girl calls c ugly Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-06-04 19:13 +0000
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-05 10:34 +0200
Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-07-12 08:32 +0000
Re: this girl calls c ugly "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-07-12 11:05 -0700
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-04 12:11 -0700
Re: this girl calls c ugly James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-06-04 16:33 -0400
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-04 14:16 -0700
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-05 00:02 +0000
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-04 18:36 -0700
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-05 02:54 +0000
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-05 05:49 -0700
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-05 11:01 -0700
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-05 11:53 -0700
Re: this girl calls c ugly Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-06-04 18:45 +0000
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-04 20:19 +0000
Re: this girl calls c ugly scott@slp53.sl.home (Scott Lurndal) - 2026-06-04 20:31 +0000
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-04 20:41 +0000
Re: this girl calls c ugly scott@slp53.sl.home (Scott Lurndal) - 2026-06-04 20:49 +0000
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-05 00:03 +0000
Re: this girl calls c ugly scott@slp53.sl.home (Scott Lurndal) - 2026-06-05 00:18 +0000
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-05 03:02 +0000
Re: this girl calls c ugly scott@slp53.sl.home (Scott Lurndal) - 2026-06-05 14:04 +0000
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-06 03:49 +0000
Re: this girl calls c ugly scott@slp53.sl.home (Scott Lurndal) - 2026-06-06 15:13 +0000
Re: this girl calls c ugly scott@slp53.sl.home (Scott Lurndal) - 2026-06-06 17:53 +0000
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-04 11:59 -0700
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-04 15:21 +0200
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-04 06:38 -0700
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-01 09:52 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-01 02:42 -0700
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-01 12:50 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-01 11:47 +0100
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-01 12:55 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-01 14:39 -0700
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-01 15:11 -0700
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-02 08:41 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-02 02:07 -0700
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-02 11:38 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-02 05:01 -0700
It is not futile to change the subject line (Was: this girl calls c ugly) gazelle@shell.xmission.com (Kenny McCormack) - 2026-06-02 12:39 +0000
Re: It is not futile to change the subject line (Was: this girl calls c ugly) gazelle@shell.xmission.com (Kenny McCormack) - 2026-06-02 12:42 +0000
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-02 11:46 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-02 11:09 +0100
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-02 05:25 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-02 14:20 +0100
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-02 15:12 -0700
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-02 04:16 -0700
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-01 15:23 -0700
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-01 16:06 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-01 23:24 +0100
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-02 11:35 +0200
Operator precedence in other (non-C, but "C-like") languages (Was: something about a girl) gazelle@shell.xmission.com (Kenny McCormack) - 2026-06-02 12:36 +0000
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-01 11:04 +0000
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-01 14:04 +0200
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-01 18:48 +0000
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-01 21:04 +0100
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-02 09:17 +0200
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-02 09:09 +0200
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-02 12:07 +0000
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-02 14:37 +0200
Microcontroller software stacks (was Re: this girl calls c ugly) scott@slp53.sl.home (Scott Lurndal) - 2026-06-02 15:06 +0000
Re: Microcontroller software stacks (was Re: this girl calls c ugly) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-21 14:13 -0700
Re: Microcontroller software stacks (was Re: this girl calls c ugly) David Brown <david.brown@hesbynett.no> - 2026-06-22 08:58 +0200
Re: Microcontroller software stacks (was Re: this girl calls c ugly) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-22 03:35 -0700
Re: Microcontroller software stacks (was Re: this girl calls c ugly) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-22 10:50 +0000
Re: Microcontroller software stacks (was Re: this girl calls c ugly) David Brown <david.brown@hesbynett.no> - 2026-06-22 12:59 +0200
Storage needed when there are bit-field members Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-28 09:42 -0700
Re: Storage needed when there are bit-field members Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-28 18:06 -0700
Re: Storage needed when there are bit-field members Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-28 20:20 -0700
Re: Storage needed when there are bit-field members Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-14 14:56 -0700
Re: Storage needed when there are bit-field members scott@slp53.sl.home (Scott Lurndal) - 2026-08-14 22:30 +0000
Re: Storage needed when there are bit-field members Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-15 16:10 -0700
Re: Storage needed when there are bit-field members scott@slp53.sl.home (Scott Lurndal) - 2026-08-16 15:20 +0000
Re: Storage needed when there are bit-field members Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-14 14:19 -0700
Re: Microcontroller software stacks (was Re: this girl calls c ugly) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-22 10:45 +0000
Re: Microcontroller software stacks (was Re: this girl calls c ugly) scott@slp53.sl.home (Scott Lurndal) - 2026-06-22 15:23 +0000
Re: Microcontroller software stacks (was Re: this girl calls c ugly) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-14 13:23 -0700
Re: Microcontroller software stacks (was Re: this girl calls c ugly) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-08-18 20:32 +0000
Re: Microcontroller software stacks (was Re: this girl calls c ugly) scott@slp53.sl.home (Scott Lurndal) - 2026-06-22 15:04 +0000
Re: Microcontroller software stacks (was Re: this girl calls c ugly) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-22 13:02 -0700
Re: Microcontroller software stacks Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-14 12:51 -0700
Re: Microcontroller software stacks Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-15 05:02 +0800
Re: Microcontroller software stacks bart <bc@freeuk.com> - 2026-08-15 01:18 +0100
Re: Microcontroller software stacks Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-16 13:52 +0800
Re: Microcontroller software stacks Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-14 14:06 -0700
Re: Microcontroller software stacks scott@slp53.sl.home (Scott Lurndal) - 2026-08-14 21:42 +0000
Re: Microcontroller software stacks Michael S <already5chosen@yahoo.com> - 2026-08-15 22:13 +0300
Re: Microcontroller software stacks scott@slp53.sl.home (Scott Lurndal) - 2026-08-15 19:39 +0000
Re: Microcontroller software stacks Michael S <already5chosen@yahoo.com> - 2026-08-15 23:22 +0300
Re: Microcontroller software stacks scott@slp53.sl.home (Scott Lurndal) - 2026-08-16 14:38 +0000
Re: Microcontroller software stacks Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-16 16:11 -0700
Re: Microcontroller software stacks Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-15 16:16 -0700
Re: Microcontroller software stacks cross@spitfire.i.gajendra.net (Dan Cross) - 2026-08-18 20:34 +0000
Re: Microcontroller software stacks Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-15 17:31 -0700
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-04 03:58 -0700
Re: this girl calls c ugly dave_thompson_2@comcast.net - 2026-06-06 19:02 -0400
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-31 19:11 +0000
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-31 16:08 -0700
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-31 16:32 -0700
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-31 17:12 -0700
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-30 14:07 +0200
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 18:10 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 19:18 +0100
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 22:17 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 21:47 +0100
Re: this girl calls c ugly James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-05-29 15:57 -0400
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 22:34 +0200
Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-29 23:18 +0000
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-30 01:26 +0100
Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-30 04:25 +0000
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-30 12:01 +0100
Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-31 00:29 +0000
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-31 10:59 +0100
Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-01 00:33 +0000
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-01 02:26 +0100
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-31 13:24 +0200
Re: this girl calls c ugly Bonita Montero <Bonita.Montero@gmail.com> - 2026-05-29 08:09 +0200
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-29 04:15 -0500
Re: this girl calls c ugly Bonita Montero <Bonita.Montero@gmail.com> - 2026-05-29 14:58 +0200
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-30 01:04 -0500
Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-29 23:20 +0000
Re: this girl calls c ugly Bonita Montero <Bonita.Montero@gmail.com> - 2026-05-30 11:18 +0200
Page 11 of 23 — ← Prev page 1 … 9 10 [11] 12 13 … 23 Next page →
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-06-10 11:10 +0100 |
| Subject | Re: Expression statements (was Re: Meaning of "expression") |
| Message-ID | <110bd6k$l31v$1@dont-email.me> |
| In reply to | #399850 |
On 10/06/2026 08:04, David Brown wrote:
> On 10/06/2026 00:34, Keith Thompson wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>> [...]
>>> "42" is an expression of type "int", and so is 'printf("Hello\n")'.
>>> How (and why) would a language distinguish between them and allow one
>>> but not the other?
>> [...]
>>
>> Ada, Pascal, and similar languages do exactly this, for what many
>> people consider to be good reasons.
>>
>
> I don't know enough about Ada to be sure, but Pascal does not do this -
> see below.
>
>> In both languages, functions and procedures are distinct. Functions
>> return values; procedures do not. An expression cannot be turned
>> into a statement just by adding a semicolon. A function call is
>> an expression. A procedure call is a statement, not an expression.
>> An assignment is a statement, not an expression.
>
> Sure. But the key factor there is that "printf", or its equivalent
> (such as "writeln", if I remember my Pascal correctly - it's been a
> while) are /procedures/. A "print" function in Pascal that returned the
> number of characters printed would be a function, used in an expression,
> not a procedure used in a statement.
>
> The rough equivalent of the distinction between Pascal procedures and
> functions is that procedures are like C functions that have "void"
> return type. It's fine (and not at all a bad idea) for a language to
> distinguish between void and non-void like this. What cannot easily be
> done in a clear and consistent way is to distinguish between two
> expressions of type "int" (or any other general non-void type).
>
> In C, an expression statement "expr;" causes the expression to be
> evaluated as a void expression for its side effects (§6.8.4p2).
In C201x draft. 6.8.4p2 is about selection statements.
> You
> can, arguably, say that C also requires all statements to be of "void"
> type, just like Pascal - but the cast-to-void is done implicitly to
> treat "expr;" as "(void) expr;".
That's not quite the same thing. If I write:
int a;
a;
then gcc -Wall will report a warning. But write it as (void)a, then it
doesn't.
While this is awkward to express in a language's grammar, it can choose
to list the kinds of expressions that /are/ allowed to be statements,
rather than leave it to the whim of an implemenation. (The ones that
aren't allowed would be a much bigger, unlimited set.)
For example:
E(...); // function call
++E; // increment
E = E; // assigment (and compound assignment)
E is any expression term. Here, the call/increment/assignment is the
top-level AST mode.
(I do this in my stuff, and there I can override the restriction using
'eval': eval a + b, which turns it into an allowed form.
Mainly this is for convenience of testing, but it was also used to
ensure an expression ended up in the primary register for subsequent
inline assembly.)
>>
>> 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). In Ada, an error in the
>> equivalent Put_Line("Hello, world") raises an exception, which
>> can't easily be ignored.
>>
>> Both approaches are valid.
>>
>
> Indeed they are.
Distinguishing between function and procedure is incredibly rare in
modern languages. There the preoccupation seems to be to unify
everything: everything is a function, even if-statements and loops.
Every function is a closure, etc. I do not consider that useful.
> It is also fine for a language to distinguish between "pure" functions
> and functions/procedures with side-effects and/or functions/procedures
> with observable behaviour. (A "pure procedure" would not do anything.)
> As far as I remember, Pascal does not make that distinction.
This goes the other way and is a better idea!
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-06-10 13:29 +0200 |
| Subject | Re: Expression statements (was Re: Meaning of "expression") |
| Message-ID | <110bhq9$lg1t$1@dont-email.me> |
| In reply to | #399856 |
On 10/06/2026 12:10, Bart wrote:
> On 10/06/2026 08:04, David Brown wrote:
>> On 10/06/2026 00:34, Keith Thompson wrote:
>>> David Brown <david.brown@hesbynett.no> writes:
>>> [...]
>>>> "42" is an expression of type "int", and so is 'printf("Hello\n")'.
>>>> How (and why) would a language distinguish between them and allow one
>>>> but not the other?
>>> [...]
>>>
>>> Ada, Pascal, and similar languages do exactly this, for what many
>>> people consider to be good reasons.
>>>
>>
>> I don't know enough about Ada to be sure, but Pascal does not do this
>> - see below.
>>
>>> In both languages, functions and procedures are distinct. Functions
>>> return values; procedures do not. An expression cannot be turned
>>> into a statement just by adding a semicolon. A function call is
>>> an expression. A procedure call is a statement, not an expression.
>>> An assignment is a statement, not an expression.
>>
>> Sure. But the key factor there is that "printf", or its equivalent
>> (such as "writeln", if I remember my Pascal correctly - it's been a
>> while) are /procedures/. A "print" function in Pascal that returned
>> the number of characters printed would be a function, used in an
>> expression, not a procedure used in a statement.
>>
>> The rough equivalent of the distinction between Pascal procedures and
>> functions is that procedures are like C functions that have "void"
>> return type. It's fine (and not at all a bad idea) for a language to
>> distinguish between void and non-void like this. What cannot easily
>> be done in a clear and consistent way is to distinguish between two
>> expressions of type "int" (or any other general non-void type).
>>
>> In C, an expression statement "expr;" causes the expression to be
>> evaluated as a void expression for its side effects (§6.8.4p2).
>
> In C201x draft. 6.8.4p2 is about selection statements.
>
C23 is the latest C standard, so that was what I was using (n3220.pdf).
It is unfortunate that C23 has slightly different numbers for some
sections - the standards authors have previously managed a higher
consistency between versions. Section 6.8.3p2 is the number for C11 (as
you have probably found already).
>> You can, arguably, say that C also requires all statements to be of
>> "void" type, just like Pascal - but the cast-to-void is done
>> implicitly to treat "expr;" as "(void) expr;".
>
> That's not quite the same thing. If I write:
>
> int a;
(Just to be clear that we agree - "int a;" is a declaration, not a
statement, expression, or expression statement.)
> a;
>
> then gcc -Wall will report a warning. But write it as (void)a, then it
> doesn't.
Yes. But that's a matter of warnings and conventional idioms, not the C
language. "a;" and "(void) a;" both mean the same thing in the C
language. gcc, like many compilers, has warnings on unused variables
and parameters, and set-but-unused variables, as these are often the
result of mistakes in the code. And tools that have such warnings have
ways to mark intentionally unused variables and parameters - such as
__attribute__(("unused")) or C23's "[[maybe_unused]]". A common idiom
is that casting an expression or variable to void tells the compiler
that you know the variable or parameter is unused, and only evaluated
for its side-effects (if any).
>
> While this is awkward to express in a language's grammar, it can choose
> to list the kinds of expressions that /are/ allowed to be statements,
> rather than leave it to the whim of an implemenation. (The ones that
> aren't allowed would be a much bigger, unlimited set.)
>
Yes, a language could do that. In C, the language chooses to allow
expressions of any type - that's the simplest to express!
> For example:
>
> E(...); // function call
> ++E; // increment
> E = E; // assigment (and compound assignment)
>
> E is any expression term. Here, the call/increment/assignment is the
> top-level AST mode.
>
> (I do this in my stuff, and there I can override the restriction using
> 'eval': eval a + b, which turns it into an allowed form.
>
> Mainly this is for convenience of testing, but it was also used to
> ensure an expression ended up in the primary register for subsequent
> inline assembly.)
A better choice for a language that wanted to restrict the kinds of
expressions that can be used as statements would be to do as Pascal does
- allow only what C would consider "void" expressions as statements, and
make things like assignment void expressions. Saying that "x = 1" is an
expression of type "int" that can be used as a statement while "x + 1"
is an expression of type "int" that cannot be used as a statement would
likely require significant complication in the language rules to work
well. Saying that "x = 1" is a void expression and can therefore be
used as a statement, while "x + 1" is a non-void expression and can
therefore not be used as a statement, is simple and clear. The cost -
or the benefit, depending on your viewpoint and preferences - is that it
is no longer possible to write "x = y = 1" or "while (x = read())...".
>
>>>
>>> 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). In Ada, an error in the
>>> equivalent Put_Line("Hello, world") raises an exception, which
>>> can't easily be ignored.
>>>
>>> Both approaches are valid.
>>>
>>
>> Indeed they are.
>
> Distinguishing between function and procedure is incredibly rare in
> modern languages. There the preoccupation seems to be to unify
> everything: everything is a function, even if-statements and loops.
> Every function is a closure, etc. I do not consider that useful.
>
Fair enough. There are pros and cons to any such choices.
>> It is also fine for a language to distinguish between "pure" functions
>> and functions/procedures with side-effects and/or functions/procedures
>> with observable behaviour. (A "pure procedure" would not do
>> anything.) As far as I remember, Pascal does not make that distinction.
>
>
> This goes the other way and is a better idea!
>
I personally think the "purity" of a function/procedure is a more
important distinction than whether or not it evaluates to a non-void.
But it is hard to see how it would work well in a compiled imperative
language - an emphasis on pure functions is more the domain of function
programming languages. But a discussion on that would be more for
comp.lang.misc than comp.lang.c
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-06-10 03:17 -0700 |
| Subject | Re: Expression statements (was Re: Meaning of "expression") |
| Message-ID | <110bdk5$l8nu$1@kst.eternal-september.org> |
| In reply to | #399850 |
David Brown <david.brown@hesbynett.no> writes:
> On 10/06/2026 00:34, Keith Thompson wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>> [...]
>>> "42" is an expression of type "int", and so is 'printf("Hello\n")'.
>>> How (and why) would a language distinguish between them and allow one
>>> but not the other?
>> [...]
>> Ada, Pascal, and similar languages do exactly this, for what many
>> people consider to be good reasons.
>
> I don't know enough about Ada to be sure, but Pascal does not do this
> - see below.
You seem to disagree with me, but then you describe most of what
I wrote. I'm not sure where you disagree, or where our signals
got crossed.
Ada and Pascal don't have expression statements. The Pascal
(writeln(...)) and Ada (Put_Line(...)) constructs most similar
to C's printf("Hello\n") are procedure calls. 42 can't made into
a statement by adding a semicolon. Neither can any function call.
But a procedure call can. That's how and why Pascal and Ada allow
one but not the other. (And both languages deliberately make it
awkward to ignore the value returned by a function.)
>> In both languages, functions and procedures are distinct. Functions
>> return values; procedures do not. An expression cannot be turned
>> into a statement just by adding a semicolon. A function call is
>> an expression. A procedure call is a statement, not an expression.
>> An assignment is a statement, not an expression.
>
> Sure. But the key factor there is that "printf", or its equivalent
> (such as "writeln", if I remember my Pascal correctly - it's been a
> while) are /procedures/. A "print" function in Pascal that returned
> the number of characters printed would be a function, used in an
> expression, not a procedure used in a statement.
Right, and a Pascal function that prints its argument and returns an
integer value could not be used by itself as a statement.
> The rough equivalent of the distinction between Pascal procedures and
> functions is that procedures are like C functions that have "void"
> return type. It's fine (and not at all a bad idea) for a language to
> distinguish between void and non-void like this. What cannot easily
> be done in a clear and consistent way is to distinguish between two
> expressions of type "int" (or any other general non-void type).
Right. Which is why the I/O and similar subroutines that you'd want to
use as statements are procedures, not functions.
[...]
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-06-10 13:43 +0200 |
| Subject | Re: Expression statements (was Re: Meaning of "expression") |
| Message-ID | <110bik6$lg1t$2@dont-email.me> |
| In reply to | #399857 |
On 10/06/2026 12:17, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 10/06/2026 00:34, Keith Thompson wrote:
>>> David Brown <david.brown@hesbynett.no> writes:
>>> [...]
>>>> "42" is an expression of type "int", and so is 'printf("Hello\n")'.
>>>> How (and why) would a language distinguish between them and allow one
>>>> but not the other?
>>> [...]
>>> Ada, Pascal, and similar languages do exactly this, for what many
>>> people consider to be good reasons.
>>
>> I don't know enough about Ada to be sure, but Pascal does not do this
>> - see below.
>
> You seem to disagree with me, but then you describe most of what
> I wrote. I'm not sure where you disagree, or where our signals
> got crossed.
>
It was most likely a misunderstanding or misinterpretation of what you
wrote - or what I wrote in the earlier post. We agree on how Pascal
(and, AFAIUI, Ada) work, and we can let that stand as a clarification
rather than risk yet another endless thread on the details of exactly
what words were used.
> Ada and Pascal don't have expression statements. The Pascal
> (writeln(...)) and Ada (Put_Line(...)) constructs most similar
> to C's printf("Hello\n") are procedure calls. 42 can't made into
> a statement by adding a semicolon. Neither can any function call.
> But a procedure call can. That's how and why Pascal and Ada allow
> one but not the other. (And both languages deliberately make it
> awkward to ignore the value returned by a function.)
Agreed.
>
>>> In both languages, functions and procedures are distinct. Functions
>>> return values; procedures do not. An expression cannot be turned
>>> into a statement just by adding a semicolon. A function call is
>>> an expression. A procedure call is a statement, not an expression.
>>> An assignment is a statement, not an expression.
>>
>> Sure. But the key factor there is that "printf", or its equivalent
>> (such as "writeln", if I remember my Pascal correctly - it's been a
>> while) are /procedures/. A "print" function in Pascal that returned
>> the number of characters printed would be a function, used in an
>> expression, not a procedure used in a statement.
>
> Right, and a Pascal function that prints its argument and returns an
> integer value could not be used by itself as a statement.
Agreed.
>
>> The rough equivalent of the distinction between Pascal procedures and
>> functions is that procedures are like C functions that have "void"
>> return type. It's fine (and not at all a bad idea) for a language to
>> distinguish between void and non-void like this. What cannot easily
>> be done in a clear and consistent way is to distinguish between two
>> expressions of type "int" (or any other general non-void type).
>
> Right. Which is why the I/O and similar subroutines that you'd want to
> use as statements are procedures, not functions.
>
That is often the case, but is certainly not required by the language.
Even standard functions can have side-effects (like "random"), though
idiomatic Pascal typically uses procedures where the results are
obtained by passing result variables by reference.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-06-10 14:08 -0700 |
| Subject | Re: Expression statements (was Re: Meaning of "expression") |
| Message-ID | <110cjp5$116qm$1@kst.eternal-september.org> |
| In reply to | #399850 |
David Brown <david.brown@hesbynett.no> writes:
[...]
> In C, an expression statement "expr;" causes the expression to be
> evaluated as a void expression for its side effects (§6.8.4p2). You
> can, arguably, say that C also requires all statements to be of "void"
> type, just like Pascal - but the cast-to-void is done implicitly to
> treat "expr;" as "(void) expr;".
[...]
In an expression statement, the expression is "evaluated as a void
expression for its side effects". I think that's equivalent to
convert (not casting!) it to void, but the standard doesn't describe
it that way.
6.3.2.2: "If an expression of any other type [other than void]
is evaluated as a void expression, its value or designator is
discarded."
But statements have no type.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-06-11 09:10 +0200 |
| Subject | Re: Expression statements (was Re: Meaning of "expression") |
| Message-ID | <110dn15$17r3s$2@dont-email.me> |
| In reply to | #399869 |
On 10/06/2026 23:08, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: > [...] >> In C, an expression statement "expr;" causes the expression to be >> evaluated as a void expression for its side effects (§6.8.4p2). You >> can, arguably, say that C also requires all statements to be of "void" >> type, just like Pascal - but the cast-to-void is done implicitly to >> treat "expr;" as "(void) expr;". > [...] > > In an expression statement, the expression is "evaluated as a void > expression for its side effects". I think that's equivalent to > convert (not casting!) it to void, but the standard doesn't describe > it that way. Agreed (I also agree on the correction of terminology). > > 6.3.2.2: "If an expression of any other type [other than void] > is evaluated as a void expression, its value or designator is > discarded." > > But statements have no type. > Correct. I did not mean to suggest that statements in C actually have a type, and that their type is "void". It was a philosophical wandering - I was not trying to stay true to the grammar and terminology of either the C or Pascal language standards. What I meant was that if you were to think that statements /did/ have type void, the resulting language would be basically the same. It gives a way to think about C and Pascal that shows that though they appear to have a different model of statements and expressions, they are fundamentally similar - the distinction being that C has an explicit conversion to void when non-void expressions are used in a statement context.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-06-11 20:29 +0200 |
| Subject | Re: Expression statements (was Re: Meaning of "expression") |
| Message-ID | <110eups$1naub$10@dont-email.me> |
| In reply to | #399850 |
On 2026-06-10 09:04, David Brown wrote: > [...] > > The rough equivalent of the distinction between Pascal procedures and > functions is that procedures are like C functions that have "void" > return type. It's fine (and not at all a bad idea) for a language to > distinguish between void and non-void like this. What cannot easily be > done in a clear and consistent way is to distinguish between two > expressions of type "int" (or any other general non-void type). Here I cannot follow you. - The C-compiler can analyze code to do optimizations and even (as so often stated) "assume" things about the intent concerning UB and optimization but cannot value facts about types and context? - If so, then it sounds rather arbitrary. > [...] > > It is also fine for a language to distinguish between "pure" functions > and functions/procedures with side-effects and/or functions/procedures > with observable behaviour. (A "pure procedure" would not do anything.) By "would not do anything" you probably mean that it would not have side-effects on/with relatively global entities in the program? > As far as I remember, Pascal does not make that distinction. Pascal functions and procedures can affect and be affected by global entities. Predefined functions and procedures can have side effects also unrelated to global entities in the program (e.g. print effect). A procedure/function not affecting the global (or surrounding stack) environment could likely be identified. But here we're anyway talking about the (clean!) return-interface of functions (as opposed to the procedures). Janis
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-06-12 12:55 +0200 |
| Subject | Re: Expression statements (was Re: Meaning of "expression") |
| Message-ID | <110goj8$24ih1$1@dont-email.me> |
| In reply to | #399908 |
On 11/06/2026 20:29, Janis Papanagnou wrote: > On 2026-06-10 09:04, David Brown wrote: >> [...] >> >> The rough equivalent of the distinction between Pascal procedures and >> functions is that procedures are like C functions that have "void" >> return type. It's fine (and not at all a bad idea) for a language to >> distinguish between void and non-void like this. What cannot easily >> be done in a clear and consistent way is to distinguish between two >> expressions of type "int" (or any other general non-void type). > > Here I cannot follow you. - The C-compiler can analyze code to do > optimizations and even (as so often stated) "assume" things about > the intent concerning UB and optimization but cannot value facts > about types and context? - If so, then it sounds rather arbitrary. > I think this thread is getting difficult to follow - there is a lot of wandering and vagueness (mostly from me, I must admit). So I am not sure if it is worth pursuing further. However, what I am trying to say is that it is easy for a programming language design to make a distinction between "things that result in a value of a type like int" and "things that do not result in a value" - and then the language could decide that the former are "expressions" that cannot stand alone, and the later are "statements". It is much harder for a language description to say that /some/ "things that result in a value of a type like int" can be used as "statements", while others can be used only as "expressions" and not stand-alone statements. >> [...] >> >> It is also fine for a language to distinguish between "pure" functions >> and functions/procedures with side-effects and/or functions/procedures >> with observable behaviour. (A "pure procedure" would not do anything.) > > By "would not do anything" you probably mean that it would not have > side-effects on/with relatively global entities in the program? Yes. A "pure" function is one whose output depends entirely on its input parameters, and has no side-effects. (Some details of the definition may be varied, such as the ability to read global data that never changes after the first call. Perhaps memoizing might also be allowed.) If you don't use the value of a call to a pure function - or if the pure function does not return a value - then it can't do anything useful. > >> As far as I remember, Pascal does not make that distinction. > > Pascal functions and procedures can affect and be affected by global > entities. Predefined functions and procedures can have side effects > also unrelated to global entities in the program (e.g. print effect). > A procedure/function not affecting the global (or surrounding stack) > environment could likely be identified. But here we're anyway talking > about the (clean!) return-interface of functions (as opposed to the > procedures). > That all agrees with what I thought.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-06-13 15:01 +0200 |
| Subject | Re: Expression statements (was Re: Meaning of "expression") |
| Message-ID | <110jkbi$2097u$5@dont-email.me> |
| In reply to | #399965 |
On 2026-06-12 12:55, David Brown wrote: > On 11/06/2026 20:29, Janis Papanagnou wrote: >> [...] > > I think this thread is getting difficult to follow - there is a lot of > wandering and vagueness (mostly from me, I must admit). So I am not > sure if it is worth pursuing further. I agree, and I appreciate your post to clarify some things. - Thanks. Janis > [...]
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-06-11 20:12 +0200 |
| Subject | Re: Expression statements (was Re: Meaning of "expression") |
| Message-ID | <110etqg$1naub$9@dont-email.me> |
| In reply to | #399834 |
On 2026-06-10 00:34, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
> [...]
>> "42" is an expression of type "int", and so is 'printf("Hello\n")'.
>> How (and why) would a language distinguish between them and allow one
>> but not the other?
> [...]
>
> Ada, Pascal, and similar languages do exactly this, for what many
> people consider to be good reasons.
Right.
What I'm not sure about is the predominance of "these" or "those"
languages. - Is that clear distinction of procedures and function
the typical case, or are the "C-derived" languages predominant and
languages with a clear distinction (meanwhile?) just outliers?
There's of course also other languages that distinguish procedures
from functions "only" by the 'void' "return type", but are anyway
able to diagnose the appropriate context and emit error messages
when inappropriately used.
>
> In both languages, functions and procedures are distinct. Functions
> return values; procedures do not. An expression cannot be turned
> into a statement just by adding a semicolon. A function call is
> an expression. A procedure call is a statement, not an expression.
> An assignment is a statement, not an expression.
>
> 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. ;-)
Janis
> [...]
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2026-06-11 15:13 -0400 |
| Subject | Re: Expression statements (was Re: Meaning of "expression") |
| Message-ID | <110f1c5$1ltqf$1@dont-email.me> |
| In reply to | #399907 |
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?
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-06-12 00:37 +0200 |
| Subject | Re: Expression statements (was Re: Meaning of "expression") |
| Message-ID | <110fdaf$1naub$11@dont-email.me> |
| In reply to | #399910 |
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.
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.
Concerning the "guarantees" that you're asking for I sadly have to say
that I meanwhile expect nothing sensible at all any more from "C". ;-)
But to be more serious again...
The man-page is very unspecific on that; 'man 3 printf' says:
"If an output error is encountered, a negative value is returned."
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?)
But yes, I'm aware of negative OS function or library function output.
Our rules (back in my C/C++ days) suggested to catch any sensible and
possible error indications to quickly localize any potential issues.
Janis
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-06-11 23:05 +0000 |
| Subject | Re: Expression statements (was Re: Meaning of "expression") |
| Message-ID | <NaHWR.151941$N9we.15064@fx16.iad> |
| In reply to | #399918 |
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>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.
The manual page also notes for the cases where printf returns -1:
For the conditions under which [CX] [Option Start] dprintf(), [Option End] fprintf(),
and printf() fail and may fail, refer to fputc() or fputwc().
In addition, all forms of fprintf() shall fail if:
[EILSEQ]
[CX] [Option Start] A wide-character code that does not correspond to a valid character has been detected. [Option End]
[EOVERFLOW]
[CX] [Option Start] The value to be returned is greater than {INT_MAX}. [Option End]
[CX] [Option Start] The asprintf() function shall fail if:
[ENOMEM]
Insufficient storage space is available.
The dprintf() function may fail if:
[EBADF]
The fildes argument is not a valid file descriptor.
[Option End]
The [CX] [Option Start] dprintf(), [Option End] fprintf(), and printf() functions may fail if:
[ENOMEM]
[CX] [Option Start] Insufficient storage space is available. [Option End]
The fputc(3) errors:
ERRORS
The fputc() function shall fail if either the stream is unbuffered or the stream's buffer needs to be flushed, and:
[EAGAIN]
[CX] [Option Start] The O_NONBLOCK flag is set for the file descriptor underlying stream and the thread would be delayed in the write operation. [Option End]
[EBADF]
[CX] [Option Start] The file descriptor underlying stream is not a valid file descriptor open for writing. [Option End]
[EFBIG]
[CX] [Option Start] An attempt was made to write to a file that exceeds the maximum file size. [Option End]
[EFBIG]
[CX] [Option Start] An attempt was made to write to a file that exceeds the file size limit of the process.
[Option End] [XSI] [Option Start] A SIGXFSZ signal shall also be generated for the thread. [Option End]
[EFBIG]
[CX] [Option Start] The file is a regular file and an attempt was made to write at or beyond the offset maximum. [Option End]
[EINTR]
[CX] [Option Start] The write operation was terminated due to the receipt of a signal, and no data was transferred. [Option End]
[EIO]
[CX] [Option Start] A physical I/O error has occurred, or the process is a member of a background process group attempting to write to its controlling terminal, TOSTOP is set, the calling thread is not blocking SIGTTOU, the process is not ignoring SIGTTOU, and the process group of the process is orphaned. This error may also be returned under implementation-defined conditions. [Option End]
[ENOSPC]
[CX] [Option Start] There was no free space remaining on the device containing the file. [Option End]
[EPIPE]
[CX] [Option Start] An attempt is made to write to a pipe or FIFO that is not open for reading by any process. A SIGPIPE signal shall also be sent to the thread. [Option End]
The fputc() function may fail if:
[ENOMEM]
[CX] [Option Start] Insufficient storage space is available. [Option End]
[ENXIO]
[CX] [Option Start] A request was made of a nonexistent device, or the request was outside the capabilities of the device. [Option End]
The '[Option start]' '[Option end]' tags describe behavior aligned with the C standard.
https://pubs.opengroup.org/onlinepubs/9799919799/functions/fputc.html
https://pubs.opengroup.org/onlinepubs/9799919799/functions/printf.html
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-06-12 01:18 +0200 |
| Subject | Re: Expression statements (was Re: Meaning of "expression") |
| Message-ID | <110ffnp$1nauc$9@dont-email.me> |
| In reply to | #399922 |
On 2026-06-12 01:05, Scott Lurndal wrote: > > The manual page also notes for the cases where printf returns -1: The man page on my Linux doesn't. :-( > [snip error list] Thanks for the error list. > [snip opengroup-links] Yeah, and these links; always useful to look up these resources. Janis
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-06-11 17:41 -0700 |
| Subject | Re: Expression statements (was Re: Meaning of "expression") |
| Message-ID | <110fkk2$1qf9f$2@kst.eternal-september.org> |
| In reply to | #399918 |
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
> 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.
Linux has a device called "/dev/full". It acts like it has no data
on input, and like it's full on output. You can redirect a program's
stdout to /dev/full. It's useful for testing, and much easier than
finding a writable filesystem with no remaining space. (/dev/null
accepts and discards as much intput as you send to it.)
On my system, a small write to /dev/full will typically succeed, since
the output is buffered rather than being immediately sent to the
file. It fails with ENOSPC after about 4 kbytes.
If I use fopen() to open /dev/full, then write to it, then fclose()
it, the fclose() fails. Since files are implicitly closed when
main() finishes, this is likely to go undetected.
A common pattern is "some_program > some_file", which redirects
stdout to a file but leaves stderr going to the default (typically
the tty).
> 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.
Calling printf with a mismatch between the format string and
an argument has undefined behavior. Some compilers will warn
about this in most cases, but in general the format string is not
necessarily known at compile time. No diagnostic or other error
indication is required.
> Concerning the "guarantees" that you're asking for I sadly have to say
> that I meanwhile expect nothing sensible at all any more from "C". ;-)
>
> But to be more serious again...
>
> The man-page is very unspecific on that; 'man 3 printf' says:
> "If an output error is encountered, a negative value is returned."
>
> 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.. */
> }
Quick-and-dirty programs like the classic "hello, world" often don't
bother to check. The above could print an error message to stderr and
call exit(EXIT_FAILURE). Even if stdout and stderr both produce errors,
the caller should be able to detect the error status. (I've configured
my shell to print a message when a program dies with an error status.)
But most production programs don't just blindly print stuff to stdout.
For example, GNU coreutils "cat" and "echo" both print "write error:
No space left on device" on stderr and exit with a status of 1 when
output is redirected to /dev/full -- if the output is big enough.
I haven't checked the source, but they must be explicitly checking
the result of both whatever output routine(s) they use and the
fclose(), or perhaps doing some fancy system-specific stuff that
has the same effect.
> 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?)
Write the error message to stderr, optionally log it somewhere,
and exit with an error code.
> But yes, I'm aware of negative OS function or library function output.
>
> Our rules (back in my C/C++ days) suggested to catch any sensible and
> possible error indications to quickly localize any potential issues.
--
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-28 02:49 +0200 |
| Subject | Re: Expression statements (was Re: Meaning of "expression") |
| Message-ID | <111pr2q$5rbd$1@dont-email.me> |
| In reply to | #399930 |
On 2026-06-12 02:41, Keith Thompson wrote:
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>>
>> 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.
>
> Linux has a device called "/dev/full". It acts like it has no data
> on input, and like it's full on output. You can redirect a program's
> stdout to /dev/full. It's useful for testing, and much easier than
> finding a writable filesystem with no remaining space. (/dev/null
> accepts and discards as much intput as you send to it.)
I've never stumbled across /dev/full before. Thanks for that hint.
> [...]
>
>> 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.
>
> Calling printf with a mismatch between the format string and
> an argument has undefined behavior. Some compilers will warn
> about this in most cases, but in general the format string is not
> necessarily known at compile time.
Well, yes. But therefore I imagined that at runtime an rc<0 could have
indicated such a mismatch.
(BTW, only after my post I noticed that my example scenario ("printing
a string value with a '%d'") a string is actually passed as a pointer
value, so is a type similar to an integer, which might make it easier
to spot at compile time than at runtime? Anyway; this is something I'd
like to be detected.)
> No diagnostic or other error indication is required.
Well.
>> [...]
>>
>> 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.. */
>> }
>
> Quick-and-dirty programs like the classic "hello, world" often don't
> bother to check. The above could print an error message to stderr and
> call exit(EXIT_FAILURE). Even if stdout and stderr both produce errors,
> the caller should be able to detect the error status. (I've configured
> my shell to print a message when a program dies with an error status.)
>
> But most production programs don't just blindly print stuff to stdout.
> [...]
>
>> 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?)
>
> Write the error message to stderr, optionally log it somewhere,
> and exit with an error code.
Just note that generally a terminal might not be connected. As I wrote,
logging was what we've done, so I'm with you here. An exit, OTOH, was in
our server applications not an option.
Janis
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-06-27 21:00 -0700 |
| Subject | Re: Expression statements (was Re: Meaning of "expression") |
| Message-ID | <111q697$3cgp8$1@kst.eternal-september.org> |
| In reply to | #400266 |
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
> On 2026-06-12 02:41, Keith Thompson wrote:
[...]
>> Calling printf with a mismatch between the format string and
>> an argument has undefined behavior. Some compilers will warn
>> about this in most cases, but in general the format string is not
>> necessarily known at compile time.
>
> Well, yes. But therefore I imagined that at runtime an rc<0 could have
> indicated such a mismatch.
That would be nice, but it's just one of the infinitely many possible
results of undefined behavior.
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).
--
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-28 09:52 -0700 |
| Subject | Re: Expression statements (was Re: Meaning of "expression") |
| Message-ID | <86qzlq7gkr.fsf@linuxsc.com> |
| In reply to | #400268 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>
>> On 2026-06-12 02:41, Keith Thompson wrote:
>
> [...]
>
>>> Calling printf with a mismatch between the format string and an
>>> argument has undefined behavior. Some compilers will warn about
>>> this in most cases, but in general the format string is not
>>> necessarily known at compile time.
>>
>> Well, yes. But therefore I imagined that at runtime an rc<0
>> could have indicated such a mismatch.
>
> That would be nice, but it's just one of the infinitely many
> possible results of undefined behavior.
>
> 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.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-06-28 18:28 -0700 |
| Subject | Re: Expression statements (was Re: Meaning of "expression") |
| Message-ID | <111shoe$3vq40$3@kst.eternal-september.org> |
| In reply to | #400274 |
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.
--
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-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]
Page 11 of 23 — ← Prev page 1 … 9 10 [11] 12 13 … 23 Next page →
Back to top | Article view | comp.lang.c
csiph-web