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 469 — 24 participants |
Back to article view | Back to comp.lang.c
this girl calls c ugly fir <profesor.fir@gmail.com> - 2026-05-27 19:53 +0200
Re: this girl calls c ugly fir <profesor.fir@gmail.com> - 2026-05-27 20:15 +0200
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-27 18:49 -0500
Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-28 04:53 +0000
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-28 02:35 -0500
Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-28 23:32 +0000
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-28 20:07 -0500
Re: this girl calls c ugly Bonita Montero <Bonita.Montero@gmail.com> - 2026-05-28 11:48 +0200
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-28 09:18 +0200
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-28 04:57 -0500
Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-28 23:35 +0000
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 09:52 +0200
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-29 05:20 -0500
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-29 13:22 +0200
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-29 15:16 -0500
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-30 13:52 +0200
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-30 14:40 +0200
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-30 16:36 +0200
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-30 15:48 -0500
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-31 11:14 +0200
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-31 13:25 -0500
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-31 22:14 +0200
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 15:22 +0200
Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-30 03:49 +0000
Re: this girl calls c ugly "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-05-28 12:47 -0700
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 09:56 +0200
Re: this girl calls c ugly "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-05-29 11:00 -0700
Re: this girl calls c ugly fir <profesor.fir@gmail.com> - 2026-05-28 17:12 +0200
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-28 14:07 -0500
Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-28 23:54 +0000
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 10:02 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 12:19 +0100
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 14:46 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 14:22 +0100
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 17:15 +0200
Re: this girl calls c ugly scott@slp53.sl.home (Scott Lurndal) - 2026-05-29 15:59 +0000
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 17:12 +0100
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 18:48 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 19:09 +0100
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 22:00 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 22:14 +0100
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-29 12:09 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 17:05 +0100
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 18:34 +0200
Re: this girl calls c ugly tTh <tth@none.invalid> - 2026-05-29 19:29 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 18:53 +0100
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-29 12:28 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 20:49 +0100
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 22:03 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-29 13:56 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 22:54 +0100
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-29 15:52 -0700
Re: this girl calls c ugly James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-05-29 20:31 -0400
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-30 02:03 +0100
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-29 19:02 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-30 12:12 +0100
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-30 12:29 +0000
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-30 13:56 +0100
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-30 16:43 -0700
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-31 03:37 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-30 19:53 -0700
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-02 12:16 +0200
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-31 11:47 +0200
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-02 12:55 +0200
Re: this girl calls c ugly Richard Harnden <richard.nospam@gmail.invalid> - 2026-05-31 09:12 +0100
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-31 11:49 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-31 11:10 +0100
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-31 13:18 +0200
Re: this girl calls c ugly James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-05-31 10:24 -0400
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-31 17:35 +0200
Re: this girl calls c ugly James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-05-31 12:46 -0400
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-31 22:24 +0200
Re: this girl calls c ugly James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-05-31 18:26 -0400
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-01 08:28 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-31 15:54 -0700
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-01 08:39 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-01 02:33 -0700
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-02 11:48 +0200
Re: this girl calls c ugly James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-06-02 06:37 -0400
Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-02 05:06 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-02 16:28 +0000
Re: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-04 03:37 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-04 16:31 +0000
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-04 13:36 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-04 23:49 +0000
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-04 18:04 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-06 03:10 +0000
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-05 23:50 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-08 02:20 +0000
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-08 12:39 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-08 23:15 +0000
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-08 18:51 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-09 09:46 +0000
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-09 15:07 -0700
Re: Constants and undefined behavior antispam@fricas.org (Waldek Hebisch) - 2026-06-09 01:25 +0000
Re: Constants and undefined behavior James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-06-09 18:29 -0400
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-09 16:01 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-10 12:36 +0000
Re: Constants and undefined behavior Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-11 16:49 +0200
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-11 15:20 +0000
Re: Constants and undefined behavior Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-11 18:08 +0200
Re: Constants and undefined behavior antispam@fricas.org (Waldek Hebisch) - 2026-06-11 16:30 +0000
Re: Constants and undefined behavior Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-11 20:52 +0200
Re: Constants and undefined behavior antispam@fricas.org (Waldek Hebisch) - 2026-06-12 02:20 +0000
Re: Constants and undefined behavior Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-13 14:57 +0200
Re: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-21 15:26 -0700
Re: Constants and undefined behavior antispam@fricas.org (Waldek Hebisch) - 2026-06-22 03:40 +0000
Re: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-15 07:50 -0700
Re: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-21 14:26 -0700
Re: Constants and undefined behavior antispam@fricas.org (Waldek Hebisch) - 2026-06-22 03:56 +0000
Re: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-29 06:27 -0700
Re: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-06 15:47 -0700
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-06 16:36 -0700
Re: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-06 16:43 -0700
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-06 17:41 -0700
Re: Constants and undefined behavior Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-05 10:41 +0200
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-05 10:49 -0700
Re: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-06 16:15 -0700
Re: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-06 18:06 -0700
Re: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-07 22:34 -0700
Re: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-08 23:05 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-09 10:19 +0000
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-09 15:12 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-10 14:37 +0000
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-10 18:30 +0000
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-10 14:55 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-10 23:32 +0000
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-10 14:47 -0700
Re: Constants and undefined behavior David Brown <david.brown@hesbynett.no> - 2026-06-11 08:56 +0200
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-11 11:38 +0000
Re: Constants and undefined behavior David Brown <david.brown@hesbynett.no> - 2026-06-11 14:05 +0200
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-11 15:38 -0700
Re: Constants and undefined behavior scott@slp53.sl.home (Scott Lurndal) - 2026-06-11 23:07 +0000
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-11 17:43 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-12 02:02 +0000
Re: Constants and undefined behavior Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-11 17:34 +0200
Re: Constants and undefined behavior David Brown <david.brown@hesbynett.no> - 2026-06-12 10:58 +0200
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-12 12:27 -0700
Re: Constants and undefined behavior David Brown <david.brown@hesbynett.no> - 2026-06-13 12:36 +0200
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-13 12:03 +0000
Re: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-14 12:35 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-13 12:02 +0000
Re: Constants and undefined behavior ram@zedat.fu-berlin.de (Stefan Ram) - 2026-06-13 12:13 +0000
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-13 12:44 +0000
Re: Constants and undefined behavior ram@zedat.fu-berlin.de (Stefan Ram) - 2026-06-14 17:22 +0000
Re: Constants and undefined behavior scott@slp53.sl.home (Scott Lurndal) - 2026-06-14 21:24 +0000
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-15 17:52 +0000
Re: Constants and undefined behavior David Brown <david.brown@hesbynett.no> - 2026-06-13 18:32 +0200
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-14 14:33 +0000
Re: Constants and undefined behavior David Brown <david.brown@hesbynett.no> - 2026-06-14 22:02 +0200
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-14 15:55 -0700
Re: Constants and undefined behavior David Brown <david.brown@hesbynett.no> - 2026-06-15 10:09 +0200
Re: Constants and undefined behavior antispam@fricas.org (Waldek Hebisch) - 2026-06-15 10:43 +0000
Re: Constants and undefined behavior David Brown <david.brown@hesbynett.no> - 2026-06-15 16:01 +0200
Re: Constants and undefined behavior antispam@fricas.org (Waldek Hebisch) - 2026-06-15 17:57 +0000
Re: Constants and undefined behavior David Brown <david.brown@hesbynett.no> - 2026-06-16 10:10 +0200
Re: Constants and undefined behavior Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-24 17:45 +0200
Re: Constants and undefined behavior "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-24 12:27 -0700
Re: Constants and undefined behavior Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-24 16:58 +0200
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-15 19:26 +0000
Re: Constants and undefined behavior James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-06-15 21:59 -0400
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-16 04:59 +0000
Re: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-29 05:41 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-29 15:23 +0000
Re: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-15 07:36 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-08-18 20:27 +0000
Re: Constants and undefined behavior Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-20 04:12 +0800
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-11 13:29 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-12 02:08 +0000
Re: Constants and undefined behavior David Brown <david.brown@hesbynett.no> - 2026-06-12 11:02 +0200
Re: Constants and undefined behavior Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-11 17:45 +0200
Re: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-10 15:11 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-10 22:44 +0000
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-10 16:19 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-11 11:50 +0000
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-11 16:28 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-11 23:46 +0000
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-11 18:29 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-12 01:54 +0000
Re: Constants and undefined behavior David Brown <david.brown@hesbynett.no> - 2026-06-12 11:37 +0200
Re: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-15 07:58 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-08-18 20:28 +0000
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-02 05:35 -0700
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-02 06:29 -0700
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-02 16:10 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-02 15:29 -0700
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-05 06:41 -0700
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-05 11:24 -0700
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-08 08:35 -0700
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-08 17:33 +0000
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-09 00:54 -0700
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-09 10:08 +0000
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-08 13:40 -0700
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-15 09:37 -0700
Meaning of "expression" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-08 14:05 -0700
Expression statements (was Re: Meaning of "expression") Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-09 15:17 +0200
Re: Expression statements (was Re: Meaning of "expression") Bart <bc@freeuk.com> - 2026-06-09 14:53 +0100
Re: Expression statements (was Re: Meaning of "expression") Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-09 16:30 +0200
Re: Expression statements (was Re: Meaning of "expression") David Brown <david.brown@hesbynett.no> - 2026-06-09 17:13 +0200
Re: Expression statements (was Re: Meaning of "expression") Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-09 15:34 -0700
Re: Expression statements (was Re: Meaning of "expression") David Brown <david.brown@hesbynett.no> - 2026-06-10 09:04 +0200
Re: Expression statements (was Re: Meaning of "expression") Bart <bc@freeuk.com> - 2026-06-10 11:10 +0100
Re: Expression statements (was Re: Meaning of "expression") David Brown <david.brown@hesbynett.no> - 2026-06-10 13:29 +0200
Re: Expression statements (was Re: Meaning of "expression") Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-10 03:17 -0700
Re: Expression statements (was Re: Meaning of "expression") David Brown <david.brown@hesbynett.no> - 2026-06-10 13:43 +0200
Re: Expression statements (was Re: Meaning of "expression") Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-10 14:08 -0700
Re: Expression statements (was Re: Meaning of "expression") David Brown <david.brown@hesbynett.no> - 2026-06-11 09:10 +0200
Re: Expression statements (was Re: Meaning of "expression") Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-11 20:29 +0200
Re: Expression statements (was Re: Meaning of "expression") David Brown <david.brown@hesbynett.no> - 2026-06-12 12:55 +0200
Re: Expression statements (was Re: Meaning of "expression") Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-13 15:01 +0200
Re: Expression statements (was Re: Meaning of "expression") Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-11 20:12 +0200
Re: Expression statements (was Re: Meaning of "expression") James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-06-11 15:13 -0400
Re: Expression statements (was Re: Meaning of "expression") Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-12 00:37 +0200
Re: Expression statements (was Re: Meaning of "expression") scott@slp53.sl.home (Scott Lurndal) - 2026-06-11 23:05 +0000
Re: Expression statements (was Re: Meaning of "expression") Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-12 01:18 +0200
Re: Expression statements (was Re: Meaning of "expression") Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-11 17:41 -0700
Re: Expression statements (was Re: Meaning of "expression") Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-28 02:49 +0200
Re: Expression statements (was Re: Meaning of "expression") Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-27 21:00 -0700
Re: Expression statements (was Re: Meaning of "expression") Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-28 09:52 -0700
Re: Expression statements (was Re: Meaning of "expression") Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-28 18:28 -0700
Re: Expression statements (was Re: Meaning of "expression") Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-14 13:40 -0700
Re: Expression statements (was Re: Meaning of "expression") Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-14 14:13 -0700
Re: Expression statements (was Re: Meaning of "expression") Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-19 08:32 -0700
Re: Expression statements (was Re: Meaning of "expression") Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-19 15:09 -0700
Re: Expression statements (was Re: Meaning of "expression") James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-06-11 20:41 -0400
Re: Expression statements (was Re: Meaning of "expression") Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-28 03:16 +0200
Re: Expression statements (was Re: Meaning of "expression") tTh <tth@none.invalid> - 2026-06-09 19:27 +0200
Re: Expression statements (was Re: Meaning of "expression") Bart <bc@freeuk.com> - 2026-06-09 19:19 +0100
Re: Expression statements (was Re: Meaning of "expression") Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-09 15:22 -0700
Re: Meaning of "expression" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-15 00:42 -0700
The meaning of 42 ; (was: Re: Meaning of "expression") Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-15 19:42 +0800
Re: Meaning of "expression" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-15 05:36 -0700
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-06 03:22 +0000
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-05 23:56 -0700
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-07 13:37 +0000
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-07 15:09 -0700
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-08 02:33 +0000
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-15 09:37 -0700
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-15 17:29 -0700
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-08-18 20:30 +0000
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-08 00:16 -0700
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-08 12:41 +0000
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-08 17:37 +0000
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-09 16:05 +0200
Re: this girl calls c ugly "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-02 13:59 -0700
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-02 13:05 +0000
Parentheses (was: this girl calls c ugly) Bart <bc@freeuk.com> - 2026-06-02 14:38 +0100
Re: Parentheses (was: this girl calls c ugly) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-02 15:19 +0000
Re: Parentheses antispam@fricas.org (Waldek Hebisch) - 2026-06-03 22:30 +0000
Re: Parentheses Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-03 16:24 -0700
Re: Parentheses antispam@fricas.org (Waldek Hebisch) - 2026-06-04 02:03 +0000
Re: Parentheses Bart <bc@freeuk.com> - 2026-06-04 01:12 +0100
Re: Parentheses antispam@fricas.org (Waldek Hebisch) - 2026-06-04 01:58 +0000
Re: Parentheses Bart <bc@freeuk.com> - 2026-06-04 11:37 +0100
Re: Parentheses cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-04 10:51 +0000
Re: Parentheses Bart <bc@freeuk.com> - 2026-06-04 12:47 +0100
Re: Parentheses Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-04 14:57 +0200
Re: Parentheses cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-04 14:31 +0000
[OT] Fancy graphics (was Re: this girl calls c ugly) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-02 15:54 +0200
Re: [OT] Fancy graphics (was Re: this girl calls c ugly) Bart <bc@freeuk.com> - 2026-06-02 15:19 +0100
Re: [OT] Fancy graphics (was Re: this girl calls c ugly) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-02 15:19 +0000
Re: [OT] Fancy graphics (was Re: this girl calls c ugly) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-02 17:39 +0200
Re: [OT] Fancy graphics (was Re: this girl calls c ugly) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-02 16:36 +0000
Re: [OT] Fancy graphics (was Re: this girl calls c ugly) scott@slp53.sl.home (Scott Lurndal) - 2026-06-02 21:33 +0000
Re: [OT] Fancy graphics (was Re: this girl calls c ugly) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-02 14:43 -0700
Re: [OT] Fancy graphics (was Re: this girl calls c ugly) ram@zedat.fu-berlin.de (Stefan Ram) - 2026-06-02 17:08 +0000
Re: [OT] Fancy graphics (was Re: this girl calls c ugly) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-02 19:19 +0000
Re: [OT] Fancy graphics (was Re: this girl calls c ugly) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-04 00:11 +0000
Re: [OT] Fancy graphics (was Re: this girl calls c ugly) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-02 15:39 -0700
Re: [OT] Fancy graphics (was Re: this girl calls c ugly) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-03 13:14 +0000
Re: this girl calls c ugly scott@slp53.sl.home (Scott Lurndal) - 2026-06-02 15:10 +0000
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-02 15:31 +0000
Re: this girl calls c ugly James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-05-31 10:15 -0400
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-31 16:29 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-31 03:45 -0700
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-31 04:02 -0700
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-31 09:04 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-31 18:11 +0100
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-31 19:34 +0000
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-31 19:10 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-01 11:12 +0100
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-01 12:36 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-01 14:26 -0700
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-04 02:34 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-04 12:40 +0100
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-04 14:35 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-04 14:18 +0100
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-04 15:47 +0200
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-04 15:57 +0200
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-04 16:27 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-04 16:46 +0100
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-04 20:15 +0200
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-04 20:54 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-04 20:29 +0100
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-04 14:06 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-04 22:47 +0100
Famous (hopefully last) words [on this topic] Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-05 00:27 +0200
Re: Famous (hopefully last) words [on this topic] Bad Post <invalid@invalid.invalid> - 2026-06-05 01:20 +0100
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-04 16:09 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-05 00:44 +0100
Re: this girl calls c ugly "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-04 17:26 -0700
Re: this girl calls c ugly antispam@fricas.org (Waldek Hebisch) - 2026-06-05 12:58 +0000
Re: this girl calls c ugly "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-05 14:27 -0700
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-05 02:47 +0000
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-05 00:53 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-05 11:04 +0100
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-05 05:34 -0700
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-06 03:45 +0000
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-06 03:44 +0000
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-06 07:39 +0200
Re: this girl calls c ugly "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-04 15:25 -0700
Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-07-12 08:31 +0000
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-05 09:29 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-05 12:39 +0100
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-05 15:42 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-05 16:50 +0100
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-05 11:09 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-05 20:29 +0100
Re: this girl calls c ugly scott@slp53.sl.home (Scott Lurndal) - 2026-06-04 16:18 +0000
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-04 17:23 +0100
Re: this girl calls c ugly scott@slp53.sl.home (Scott Lurndal) - 2026-06-04 16:47 +0000
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-04 19:57 +0100
Re: this girl calls c ugly scott@slp53.sl.home (Scott Lurndal) - 2026-06-04 20:34 +0000
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-04 22:28 +0100
Re: this girl calls c ugly scott@slp53.sl.home (Scott Lurndal) - 2026-06-04 21:58 +0000
Re: this girl calls c ugly Richard Harnden <richard.nospam@gmail.invalid> - 2026-06-04 23:25 +0100
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-05 02:49 +0000
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-04 19:47 +0200
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-04 21:04 +0200
Re: this girl calls c ugly Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-06-04 19:13 +0000
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-05 10:34 +0200
Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-07-12 08:32 +0000
Re: this girl calls c ugly "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-07-12 11:05 -0700
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-04 12:11 -0700
Re: this girl calls c ugly James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-06-04 16:33 -0400
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-04 14:16 -0700
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-05 00:02 +0000
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-04 18:36 -0700
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-05 02:54 +0000
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-05 05:49 -0700
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-05 11:01 -0700
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-05 11:53 -0700
Re: this girl calls c ugly Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-06-04 18:45 +0000
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-04 20:19 +0000
Re: this girl calls c ugly scott@slp53.sl.home (Scott Lurndal) - 2026-06-04 20:31 +0000
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-04 20:41 +0000
Re: this girl calls c ugly scott@slp53.sl.home (Scott Lurndal) - 2026-06-04 20:49 +0000
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-05 00:03 +0000
Re: this girl calls c ugly scott@slp53.sl.home (Scott Lurndal) - 2026-06-05 00:18 +0000
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-05 03:02 +0000
Re: this girl calls c ugly scott@slp53.sl.home (Scott Lurndal) - 2026-06-05 14:04 +0000
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-06 03:49 +0000
Re: this girl calls c ugly scott@slp53.sl.home (Scott Lurndal) - 2026-06-06 15:13 +0000
Re: this girl calls c ugly scott@slp53.sl.home (Scott Lurndal) - 2026-06-06 17:53 +0000
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-04 11:59 -0700
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-04 15:21 +0200
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-04 06:38 -0700
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-01 09:52 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-01 02:42 -0700
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-01 12:50 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-01 11:47 +0100
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-01 12:55 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-01 14:39 -0700
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-01 15:11 -0700
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-02 08:41 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-02 02:07 -0700
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-02 11:38 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-02 05:01 -0700
It is not futile to change the subject line (Was: this girl calls c ugly) gazelle@shell.xmission.com (Kenny McCormack) - 2026-06-02 12:39 +0000
Re: It is not futile to change the subject line (Was: this girl calls c ugly) gazelle@shell.xmission.com (Kenny McCormack) - 2026-06-02 12:42 +0000
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-02 11:46 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-02 11:09 +0100
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-02 05:25 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-02 14:20 +0100
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-02 15:12 -0700
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-02 04:16 -0700
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-01 15:23 -0700
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-01 16:06 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-01 23:24 +0100
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-02 11:35 +0200
Operator precedence in other (non-C, but "C-like") languages (Was: something about a girl) gazelle@shell.xmission.com (Kenny McCormack) - 2026-06-02 12:36 +0000
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-01 11:04 +0000
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-01 14:04 +0200
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-01 18:48 +0000
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-01 21:04 +0100
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-02 09:17 +0200
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-02 09:09 +0200
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-02 12:07 +0000
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-02 14:37 +0200
Microcontroller software stacks (was Re: this girl calls c ugly) scott@slp53.sl.home (Scott Lurndal) - 2026-06-02 15:06 +0000
Re: Microcontroller software stacks (was Re: this girl calls c ugly) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-21 14:13 -0700
Re: Microcontroller software stacks (was Re: this girl calls c ugly) David Brown <david.brown@hesbynett.no> - 2026-06-22 08:58 +0200
Re: Microcontroller software stacks (was Re: this girl calls c ugly) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-22 03:35 -0700
Re: Microcontroller software stacks (was Re: this girl calls c ugly) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-22 10:50 +0000
Re: Microcontroller software stacks (was Re: this girl calls c ugly) David Brown <david.brown@hesbynett.no> - 2026-06-22 12:59 +0200
Storage needed when there are bit-field members Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-28 09:42 -0700
Re: Storage needed when there are bit-field members Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-28 18:06 -0700
Re: Storage needed when there are bit-field members Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-28 20:20 -0700
Re: Storage needed when there are bit-field members Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-14 14:56 -0700
Re: Storage needed when there are bit-field members scott@slp53.sl.home (Scott Lurndal) - 2026-08-14 22:30 +0000
Re: Storage needed when there are bit-field members Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-15 16:10 -0700
Re: Storage needed when there are bit-field members scott@slp53.sl.home (Scott Lurndal) - 2026-08-16 15:20 +0000
Re: Storage needed when there are bit-field members antispam@fricas.org (Waldek Hebisch) - 2026-08-19 19:34 +0000
Re: Storage needed when there are bit-field members Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-19 15:26 -0700
Re: Storage needed when there are bit-field members David Brown <david.brown@hesbynett.no> - 2026-08-20 11:00 +0200
Re: Storage needed when there are bit-field members Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-20 03:30 -0700
Re: Storage needed when there are bit-field members David Brown <david.brown@hesbynett.no> - 2026-08-20 13:58 +0200
Re: Storage needed when there are bit-field members Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-20 13:37 -0700
Re: Storage needed when there are bit-field members Michael S <already5chosen@yahoo.com> - 2026-08-21 14:31 +0300
Re: Storage needed when there are bit-field members David Brown <david.brown@hesbynett.no> - 2026-08-21 13:41 +0200
Re: Storage needed when there are bit-field members scott@slp53.sl.home (Scott Lurndal) - 2026-08-21 15:41 +0000
Re: Storage needed when there are bit-field members Michael S <already5chosen@yahoo.com> - 2026-08-21 14:58 +0300
Re: Storage needed when there are bit-field members scott@slp53.sl.home (Scott Lurndal) - 2026-08-20 14:50 +0000
Re: Storage needed when there are bit-field members "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-20 12:31 -0700
Re: Storage needed when there are bit-field members antispam@fricas.org (Waldek Hebisch) - 2026-08-20 19:55 +0000
Re: Storage needed when there are bit-field members David Brown <david.brown@hesbynett.no> - 2026-08-21 08:57 +0200
Re: Storage needed when there are bit-field members scott@slp53.sl.home (Scott Lurndal) - 2026-08-21 14:59 +0000
Re: Storage needed when there are bit-field members Michael S <already5chosen@yahoo.com> - 2026-08-20 22:15 +0300
Re: Storage needed when there are bit-field members Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-14 14:19 -0700
Re: Microcontroller software stacks (was Re: this girl calls c ugly) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-22 10:45 +0000
Re: Microcontroller software stacks (was Re: this girl calls c ugly) scott@slp53.sl.home (Scott Lurndal) - 2026-06-22 15:23 +0000
Re: Microcontroller software stacks (was Re: this girl calls c ugly) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-14 13:23 -0700
Re: Microcontroller software stacks (was Re: this girl calls c ugly) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-08-18 20:32 +0000
Re: Microcontroller software stacks (was Re: this girl calls c ugly) scott@slp53.sl.home (Scott Lurndal) - 2026-06-22 15:04 +0000
Re: Microcontroller software stacks (was Re: this girl calls c ugly) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-22 13:02 -0700
Re: Microcontroller software stacks Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-14 12:51 -0700
Re: Microcontroller software stacks Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-15 05:02 +0800
Re: Microcontroller software stacks bart <bc@freeuk.com> - 2026-08-15 01:18 +0100
Re: Microcontroller software stacks Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-16 13:52 +0800
Re: Microcontroller software stacks Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-14 14:06 -0700
Re: Microcontroller software stacks scott@slp53.sl.home (Scott Lurndal) - 2026-08-14 21:42 +0000
Re: Microcontroller software stacks Michael S <already5chosen@yahoo.com> - 2026-08-15 22:13 +0300
Re: Microcontroller software stacks scott@slp53.sl.home (Scott Lurndal) - 2026-08-15 19:39 +0000
Re: Microcontroller software stacks Michael S <already5chosen@yahoo.com> - 2026-08-15 23:22 +0300
Re: Microcontroller software stacks scott@slp53.sl.home (Scott Lurndal) - 2026-08-16 14:38 +0000
Re: Microcontroller software stacks Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-16 16:11 -0700
Re: Microcontroller software stacks Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-15 16:16 -0700
Re: Microcontroller software stacks cross@spitfire.i.gajendra.net (Dan Cross) - 2026-08-18 20:34 +0000
Re: Microcontroller software stacks antispam@fricas.org (Waldek Hebisch) - 2026-08-19 19:57 +0000
Re: Microcontroller software stacks Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-15 17:31 -0700
Re: Microcontroller software stacks (was Re: this girl calls c ugly) Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-20 04:51 +0800
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-04 03:58 -0700
Re: this girl calls c ugly dave_thompson_2@comcast.net - 2026-06-06 19:02 -0400
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-31 19:11 +0000
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-31 16:08 -0700
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-31 16:32 -0700
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-31 17:12 -0700
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-30 14:07 +0200
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 18:10 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 19:18 +0100
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 22:17 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 21:47 +0100
Re: this girl calls c ugly James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-05-29 15:57 -0400
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 22:34 +0200
Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-29 23:18 +0000
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-30 01:26 +0100
Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-30 04:25 +0000
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-30 12:01 +0100
Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-31 00:29 +0000
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-31 10:59 +0100
Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-01 00:33 +0000
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-01 02:26 +0100
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-31 13:24 +0200
Re: this girl calls c ugly Bonita Montero <Bonita.Montero@gmail.com> - 2026-05-29 08:09 +0200
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-29 04:15 -0500
Re: this girl calls c ugly Bonita Montero <Bonita.Montero@gmail.com> - 2026-05-29 14:58 +0200
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-30 01:04 -0500
Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-29 23:20 +0000
Re: this girl calls c ugly Bonita Montero <Bonita.Montero@gmail.com> - 2026-05-30 11:18 +0200
Page 17 of 24 — ← Prev page 1 … 15 16 [17] 18 19 … 24 Next page →
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-06-04 16:47 +0000 |
| Message-ID | <W_hUR.11279$SHu9.2663@fx45.iad> |
| In reply to | #399692 |
Bart <bc@freeuk.com> writes: >On 04/06/2026 17:18, Scott Lurndal wrote: >> David Brown <david.brown@hesbynett.no> writes: >>> On 04/06/2026 15:18, Bart wrote: >> >>>>>> (Note that C has its own problems in this area: >>>>>> >>>>>> a = b/*p; // divide b by dereferenced pointer p >>>>>> >>>>>> Here, /* also happens to start a block comment.) >>>>>> >>>>> >>>>> Here you are objectively wrong. C does not have a "problem" with >>>>> this. The parsing rules of the language are clear - often called >>>>> "maximum munch". The character sequence "/*" is the start of a >>>>> comment, it is not two separate operators. >>>> >>>> This is where it falls down. It's very clearly a 'gotcha', and >>>> consequence of poorly thought-out design. >>> >>> It is neither a "gotcha", not a consequence of poor design. >> >> Indeed, and in the early days, the compiler itself would never >> have seen '/*' - the preprocessor (cpp) would have removed it >> from the source before the source reached the first >> pass of the compiler (c0). > >How does that not make it bad design? > >The proprocessor would strip everything from the /* until the next >matching */, so a chunk of your program goes missing. Whatcha talkin' 'bout willis?
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-06-04 19:57 +0100 |
| Message-ID | <10vshrk$jl9m$1@dont-email.me> |
| In reply to | #399694 |
On 04/06/2026 17:47, Scott Lurndal wrote: > Bart <bc@freeuk.com> writes: >> On 04/06/2026 17:18, Scott Lurndal wrote: >>> David Brown <david.brown@hesbynett.no> writes: >>>> On 04/06/2026 15:18, Bart wrote: >>> >>>>>>> (Note that C has its own problems in this area: >>>>>>> >>>>>>> a = b/*p; // divide b by dereferenced pointer p >>>>>>> >>>>>>> Here, /* also happens to start a block comment.) >>>>>>> >>>>>> >>>>>> Here you are objectively wrong. C does not have a "problem" with >>>>>> this. The parsing rules of the language are clear - often called >>>>>> "maximum munch". The character sequence "/*" is the start of a >>>>>> comment, it is not two separate operators. >>>>> >>>>> This is where it falls down. It's very clearly a 'gotcha', and >>>>> consequence of poorly thought-out design. >>>> >>>> It is neither a "gotcha", not a consequence of poor design. >>> >>> Indeed, and in the early days, the compiler itself would never >>> have seen '/*' - the preprocessor (cpp) would have removed it >>> from the source before the source reached the first >>> pass of the compiler (c0). >> >> How does that not make it bad design? >> >> The proprocessor would strip everything from the /* until the next >> matching */, so a chunk of your program goes missing. > > Whatcha talkin' 'bout willis? What were /you/ talking about? What was your point?
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-06-04 20:34 +0000 |
| Message-ID | <jjlUR.17898$pxGb.10478@fx07.iad> |
| In reply to | #399700 |
Bart <bc@freeuk.com> writes: >On 04/06/2026 17:47, Scott Lurndal wrote: >> Bart <bc@freeuk.com> writes: >>> On 04/06/2026 17:18, Scott Lurndal wrote: >>>> David Brown <david.brown@hesbynett.no> writes: >>>>> On 04/06/2026 15:18, Bart wrote: >>>> >>>>>>>> (Note that C has its own problems in this area: >>>>>>>> >>>>>>>> a = b/*p; // divide b by dereferenced pointer p >>>>>>>> >>>>>>>> Here, /* also happens to start a block comment.) >>>>>>>> >>>>>>> >>>>>>> Here you are objectively wrong. C does not have a "problem" with >>>>>>> this. The parsing rules of the language are clear - often called >>>>>>> "maximum munch". The character sequence "/*" is the start of a >>>>>>> comment, it is not two separate operators. >>>>>> >>>>>> This is where it falls down. It's very clearly a 'gotcha', and >>>>>> consequence of poorly thought-out design. >>>>> >>>>> It is neither a "gotcha", not a consequence of poor design. >>>> >>>> Indeed, and in the early days, the compiler itself would never >>>> have seen '/*' - the preprocessor (cpp) would have removed it >>>> from the source before the source reached the first >>>> pass of the compiler (c0). >>> >>> How does that not make it bad design? >>> >>> The proprocessor would strip everything from the /* until the next >>> matching */, so a chunk of your program goes missing. >> >> Whatcha talkin' 'bout willis? > > >What were /you/ talking about? What was your point? > Your inaccurate characterization that a chunk of the program went "missing". Nothing meaningful is missing (and the comment remains in the original source file). So what do you mean, exactly, when you claim that the output of the preprocessor causes a chunk of the program (which doesn't include whitespace or comments) is missing?
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-06-04 22:28 +0100 |
| Message-ID | <10vsqlu$men2$1@dont-email.me> |
| In reply to | #399709 |
On 04/06/2026 21:34, Scott Lurndal wrote:
> Bart <bc@freeuk.com> writes:
>> On 04/06/2026 17:47, Scott Lurndal wrote:
>>> Bart <bc@freeuk.com> writes:
>>>> On 04/06/2026 17:18, Scott Lurndal wrote:
>>>>> David Brown <david.brown@hesbynett.no> writes:
>>>>>> On 04/06/2026 15:18, Bart wrote:
>>>>>
>>>>>>>>> (Note that C has its own problems in this area:
>>>>>>>>>
>>>>>>>>> a = b/*p; // divide b by dereferenced pointer p
>>>>>>>>>
>>>>>>>>> Here, /* also happens to start a block comment.)
>>>>>>>>>
>>>>>>>>
>>>>>>>> Here you are objectively wrong. C does not have a "problem" with
>>>>>>>> this. The parsing rules of the language are clear - often called
>>>>>>>> "maximum munch". The character sequence "/*" is the start of a
>>>>>>>> comment, it is not two separate operators.
>>>>>>>
>>>>>>> This is where it falls down. It's very clearly a 'gotcha', and
>>>>>>> consequence of poorly thought-out design.
>>>>>>
>>>>>> It is neither a "gotcha", not a consequence of poor design.
>>>>>
>>>>> Indeed, and in the early days, the compiler itself would never
>>>>> have seen '/*' - the preprocessor (cpp) would have removed it
>>>>> from the source before the source reached the first
>>>>> pass of the compiler (c0).
>>>>
>>>> How does that not make it bad design?
>>>>
>>>> The proprocessor would strip everything from the /* until the next
>>>> matching */, so a chunk of your program goes missing.
>>>
>>> Whatcha talkin' 'bout willis?
>>
>>
>> What were /you/ talking about? What was your point?
>>
>
> Your inaccurate characterization that a chunk of the program
> went "missing". Nothing meaningful is missing (and the comment
> remains in the original source file).
>
> So what do you mean, exactly, when you claim that the output of
> the preprocessor causes a chunk of the program (which doesn't
> include whitespace or comments) is missing?
This is the example I gave elsewhere:
---------------------------
There are actually other issues associated with /**/ comments; here
someone forgot to terminate the first comment:
puts("one"); /* comment 1
puts("two"); /* commmet 2 */
puts("three"); /* comment 3 */
---------------------------
After preprocessing you're left with this:
puts("one");
puts("three");
That middle puts call is missing, and it's meant to be part of the program.
This can also be a consequence of an inadvertent /* sequence such as in
'a = b/*p;'.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-06-04 21:58 +0000 |
| Message-ID | <WxmUR.8451$S8Pc.3599@fx11.iad> |
| In reply to | #399716 |
Bart <bc@freeuk.com> writes:
>On 04/06/2026 21:34, Scott Lurndal wrote:
>> Bart <bc@freeuk.com> writes:
>>> On 04/06/2026 17:47, Scott Lurndal wrote:
>>>> Bart <bc@freeuk.com> writes:
>>>>> On 04/06/2026 17:18, Scott Lurndal wrote:
>>>>>> David Brown <david.brown@hesbynett.no> writes:
>>>>>>> On 04/06/2026 15:18, Bart wrote:
>>>>>>
>>>>>>>>>> (Note that C has its own problems in this area:
>>>>>>>>>>
>>>>>>>>>> a = b/*p; // divide b by dereferenced pointer p
>>>>>>>>>>
>>>>>>>>>> Here, /* also happens to start a block comment.)
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Here you are objectively wrong. C does not have a "problem" with
>>>>>>>>> this. The parsing rules of the language are clear - often called
>>>>>>>>> "maximum munch". The character sequence "/*" is the start of a
>>>>>>>>> comment, it is not two separate operators.
>>>>>>>>
>>>>>>>> This is where it falls down. It's very clearly a 'gotcha', and
>>>>>>>> consequence of poorly thought-out design.
>>>>>>>
>>>>>>> It is neither a "gotcha", not a consequence of poor design.
>>>>>>
>>>>>> Indeed, and in the early days, the compiler itself would never
>>>>>> have seen '/*' - the preprocessor (cpp) would have removed it
>>>>>> from the source before the source reached the first
>>>>>> pass of the compiler (c0).
>>>>>
>>>>> How does that not make it bad design?
>>>>>
>>>>> The proprocessor would strip everything from the /* until the next
>>>>> matching */, so a chunk of your program goes missing.
>>>>
>>>> Whatcha talkin' 'bout willis?
>>>
>>>
>>> What were /you/ talking about? What was your point?
>>>
>>
>> Your inaccurate characterization that a chunk of the program
>> went "missing". Nothing meaningful is missing (and the comment
>> remains in the original source file).
>>
>> So what do you mean, exactly, when you claim that the output of
>> the preprocessor causes a chunk of the program (which doesn't
>> include whitespace or comments) is missing?
>
>This is the example I gave elsewhere:
>
>---------------------------
>There are actually other issues associated with /**/ comments; here
>someone forgot to terminate the first comment:
>
> puts("one"); /* comment 1
> puts("two"); /* commmet 2 */
> puts("three"); /* comment 3 */
>---------------------------
>
>After preprocessing you're left with this:
>
> puts("one");
> puts("three");
>
>That middle puts call is missing, and it's meant to be part of the program.
Of course. There is no functional difference between removing the commented
text in cpp and leaving it in. In both cases, puts("two"); will be treated as
a comment and will be ignored by the rest of the compiler.
[toc] | [prev] | [next] | [standalone]
| From | Richard Harnden <richard.nospam@gmail.invalid> |
|---|---|
| Date | 2026-06-04 23:25 +0100 |
| Message-ID | <10vsu1h$n0dh$1@dont-email.me> |
| In reply to | #399716 |
On 04/06/2026 22:28, Bart wrote:
> There are actually other issues associated with /**/ comments; here
> someone forgot to terminate the first comment:
>
> puts("one"); /* comment 1
> puts("two"); /* commmet 2 */
> puts("three"); /* comment 3 */
I get ...
$ gcc x.c
x.c:6:21: warning: '/*' within block comment [-Wcomment]
6 | puts("two"); /* commmet 2 */
| ^
1 warning generated.
... so I don't see it as a big deal.
It's up there with typing 'foo():' when I meant 'foo();' - I'll get lots
of errors which all boil down to my inability to release the shift-key.
I don't blame the keyboard layout. Or the font. Or my eyesight.
I'm sure there are plenty of editors that have a nested-comments angry
colour.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-06-05 02:49 +0000 |
| Message-ID | <10vtdgd$id4$2@reader1.panix.com> |
| In reply to | #399716 |
In article <10vsqlu$men2$1@dont-email.me>, Bart <bc@freeuk.com> wrote:
>On 04/06/2026 21:34, Scott Lurndal wrote:
>> Bart <bc@freeuk.com> writes:
>>> On 04/06/2026 17:47, Scott Lurndal wrote:
>>>> Bart <bc@freeuk.com> writes:
>>>>> On 04/06/2026 17:18, Scott Lurndal wrote:
>>>>>> David Brown <david.brown@hesbynett.no> writes:
>>>>>>> On 04/06/2026 15:18, Bart wrote:
>>>>>>
>>>>>>>>>> (Note that C has its own problems in this area:
>>>>>>>>>>
>>>>>>>>>> a = b/*p; // divide b by dereferenced pointer p
>>>>>>>>>>
>>>>>>>>>> Here, /* also happens to start a block comment.)
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Here you are objectively wrong. C does not have a "problem" with
>>>>>>>>> this. The parsing rules of the language are clear - often called
>>>>>>>>> "maximum munch". The character sequence "/*" is the start of a
>>>>>>>>> comment, it is not two separate operators.
>>>>>>>>
>>>>>>>> This is where it falls down. It's very clearly a 'gotcha', and
>>>>>>>> consequence of poorly thought-out design.
>>>>>>>
>>>>>>> It is neither a "gotcha", not a consequence of poor design.
>>>>>>
>>>>>> Indeed, and in the early days, the compiler itself would never
>>>>>> have seen '/*' - the preprocessor (cpp) would have removed it
>>>>>> from the source before the source reached the first
>>>>>> pass of the compiler (c0).
>>>>>
>>>>> How does that not make it bad design?
>>>>>
>>>>> The proprocessor would strip everything from the /* until the next
>>>>> matching */, so a chunk of your program goes missing.
>>>>
>>>> Whatcha talkin' 'bout willis?
>>>
>>>
>>> What were /you/ talking about? What was your point?
>>>
>>
>> Your inaccurate characterization that a chunk of the program
>> went "missing". Nothing meaningful is missing (and the comment
>> remains in the original source file).
>>
>> So what do you mean, exactly, when you claim that the output of
>> the preprocessor causes a chunk of the program (which doesn't
>> include whitespace or comments) is missing?
>
>This is the example I gave elsewhere:
>
>---------------------------
>There are actually other issues associated with /**/ comments; here
>someone forgot to terminate the first comment:
>
> puts("one"); /* comment 1
> puts("two"); /* commmet 2 */
> puts("three"); /* comment 3 */
>---------------------------
>
>After preprocessing you're left with this:
>
> puts("one");
> puts("three");
>
>That middle puts call is missing, and it's meant to be part of the program.
The middle call is not "missing". It is "commented out." It
that was not deliberate, you might have a bad time, but it's
independent of the preprocessor.
>This can also be a consequence of an inadvertent /* sequence such as in
>'a = b/*p;'.
Sounds like a bug.
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-06-04 19:47 +0200 |
| Message-ID | <10vsdnd$fm4o$1@dont-email.me> |
| In reply to | #399691 |
On 2026-06-04 18:18, Scott Lurndal wrote: > > Indeed, and in the early days, the compiler itself would never > have seen '/*' - the preprocessor (cpp) would have removed it > from the source before the source reached the first > pass of the compiler (c0). Curious; was the comment-handling at some point in history removed from the Cpp-processing? - If so, when was that? And I assume the semantics are still the same; is that correct? Janis
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-06-04 21:04 +0200 |
| Message-ID | <10vsi8i$jcrh$2@dont-email.me> |
| In reply to | #399696 |
On 04/06/2026 19:47, Janis Papanagnou wrote: > On 2026-06-04 18:18, Scott Lurndal wrote: >> >> Indeed, and in the early days, the compiler itself would never >> have seen '/*' - the preprocessor (cpp) would have removed it >> from the source before the source reached the first >> pass of the compiler (c0). > > Curious; was the comment-handling at some point in history removed > from the Cpp-processing? - If so, when was that? And I assume the > semantics are still the same; is that correct? > No, at least since the standardisation of the C language (including K&R "standard"), "preprocessing" has been an integral part of the C language and conversion of comments to space characters is done in phase 3 of the translation. But the C standards do not give an explicit distinction between "preprocessing" and "compiling" - just different translation phases. (They do not define a "compiler" at all.) It is not uncommon for implementations to separate translation into two or more programs, especially in the good old days when hosts had much less memory, but logically they are all one implementation. Distinguishing "the compiler itself" is somewhat artificial.
[toc] | [prev] | [next] | [standalone]
| From | Lew Pitcher <lew.pitcher@digitalfreehold.ca> |
|---|---|
| Date | 2026-06-04 19:13 +0000 |
| Message-ID | <10vsip0$b3is$2@dont-email.me> |
| In reply to | #399702 |
On Thu, 04 Jun 2026 21:04:50 +0200, David Brown wrote:
> On 04/06/2026 19:47, Janis Papanagnou wrote:
>> On 2026-06-04 18:18, Scott Lurndal wrote:
>>>
>>> Indeed, and in the early days, the compiler itself would never
>>> have seen '/*' - the preprocessor (cpp) would have removed it
>>> from the source before the source reached the first
>>> pass of the compiler (c0).
>>
>> Curious; was the comment-handling at some point in history removed
>> from the Cpp-processing? - If so, when was that? And I assume the
>> semantics are still the same; is that correct?
>>
>
> No, at least since the standardisation of the C language (including K&R
> "standard"), "preprocessing" has been an integral part of the C language
> and conversion of comments to space characters is done in phase 3 of the
> translation. But the C standards do not give an explicit distinction
> between "preprocessing" and "compiling" - just different translation
> phases. (They do not define a "compiler" at all.) It is not uncommon
> for implementations to separate translation into two or more programs,
> especially in the good old days when hosts had much less memory, but
> logically they are all one implementation. Distinguishing "the compiler
> itself" is somewhat artificial.
In historic Unix (Version 7 and before), the preprocessor was implemented
as a separate program ("cpp") from the compiler ("cc"). The compiler itself
had no facility to handle preprocessor directives, and was, itself, often
divided into two separate programs ("cc0" and "cc1"). All three phases
("cpp", "cc0" and "cc1") were managed by a program ("cc"), although the
program for each phase could be invoked independently through manual
execution.
What differs from today is that the preprocessor was an optional component,
made available for a programmer's convenience.
--
Lew Pitcher
"In Skills We Trust"
Not LLM output - I'm just like this.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-06-05 10:34 +0200 |
| Message-ID | <10vu1lo$uv3v$2@dont-email.me> |
| In reply to | #399704 |
On 04/06/2026 21:13, Lew Pitcher wrote:
> On Thu, 04 Jun 2026 21:04:50 +0200, David Brown wrote:
>
>> On 04/06/2026 19:47, Janis Papanagnou wrote:
>>> On 2026-06-04 18:18, Scott Lurndal wrote:
>>>>
>>>> Indeed, and in the early days, the compiler itself would never
>>>> have seen '/*' - the preprocessor (cpp) would have removed it
>>>> from the source before the source reached the first
>>>> pass of the compiler (c0).
>>>
>>> Curious; was the comment-handling at some point in history removed
>>> from the Cpp-processing? - If so, when was that? And I assume the
>>> semantics are still the same; is that correct?
>>>
>>
>> No, at least since the standardisation of the C language (including K&R
>> "standard"), "preprocessing" has been an integral part of the C language
>> and conversion of comments to space characters is done in phase 3 of the
>> translation. But the C standards do not give an explicit distinction
>> between "preprocessing" and "compiling" - just different translation
>> phases. (They do not define a "compiler" at all.) It is not uncommon
>> for implementations to separate translation into two or more programs,
>> especially in the good old days when hosts had much less memory, but
>> logically they are all one implementation. Distinguishing "the compiler
>> itself" is somewhat artificial.
>
> In historic Unix (Version 7 and before), the preprocessor was implemented
> as a separate program ("cpp") from the compiler ("cc"). The compiler itself
> had no facility to handle preprocessor directives, and was, itself, often
> divided into two separate programs ("cc0" and "cc1"). All three phases
> ("cpp", "cc0" and "cc1") were managed by a program ("cc"), although the
> program for each phase could be invoked independently through manual
> execution.
>
When you type "$(CC) main.c -o main" and get a program "main", there are
usually a number of programs run in the process. Traditionally (and
still the case for some compilers) there was a split between the
"preprocessor" and the "compiler". But such a split is artificial in
terms of the C implementation - as is having the compiler generate
assembly and pass it to a separate assembler, and a separate linker. A
C implementation translates C into a program suitable for running on the
target - whether that is done using a single program or multiple
programs is implementation detail.
(In contrast, I have seen embedded C compilers where there was a single
program that covered everything - preprocessing, compiling, assembling,
linking, and also contained the standard headers and standard library as
part of the monolithic tool rather than separate files.)
> What differs from today is that the preprocessor was an optional component,
> made available for a programmer's convenience.
>
I am not sure what you mean. I can run code through a C pre-processor
without compiling it today. I can write "manually pre-processed" C code
and compile it today without a pre-processing stage. I have rarely had
use of the former (perhaps debugging some macros), and never had need of
the later, but it is certainly possible.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-07-12 08:32 +0000 |
| Message-ID | <112vjfi$2lsu8$4@dont-email.me> |
| In reply to | #399704 |
On Thu, 4 Jun 2026 19:13:36 -0000 (UTC), Lew Pitcher wrote: > What differs from today is that the preprocessor was an optional > component, made available for a programmer's convenience. It still is. Regardless of whether it’s implemented as a separate executable or as just another phase of the same compiler program, command-line options still exist to manage its functionality separately.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2026-07-12 11:05 -0700 |
| Message-ID | <1130l0o$30s27$3@dont-email.me> |
| In reply to | #400301 |
On 7/12/2026 1:32 AM, Lawrence D’Oliveiro wrote: > On Thu, 4 Jun 2026 19:13:36 -0000 (UTC), Lew Pitcher wrote: > >> What differs from today is that the preprocessor was an optional >> component, made available for a programmer's convenience. > > It still is. Big time! :^) > Regardless of whether it’s implemented as a separate > executable or as just another phase of the same compiler program, > command-line options still exist to manage its functionality > separately.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-06-04 12:11 -0700 |
| Message-ID | <10vsilh$ipkn$2@kst.eternal-september.org> |
| In reply to | #399696 |
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
> On 2026-06-04 18:18, Scott Lurndal wrote:
>> Indeed, and in the early days, the compiler itself would never
>> have seen '/*' - the preprocessor (cpp) would have removed it
>> from the source before the source reached the first
>> pass of the compiler (c0).
>
> Curious; was the comment-handling at some point in history removed
> from the Cpp-processing? - If so, when was that? And I assume the
> semantics are still the same; is that correct?
According to the standard, each comment is replaced by one space
character in translation phase 3. For implementations where the
preprocessor is a separate program, it typically handles translation
phases 1-6 or 1-7. ("gcc -E" doesn't splice string literals.)
The semantics may have been different in some ancient
implementations. For example, I vaguely recall that it was common
for ABC/**/DEF to be equivalent to ABCDEF. K&R1 says that comments
are treated as whitespace.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2026-06-04 16:33 -0400 |
| Message-ID | <10vsnfg$lahf$1@dont-email.me> |
| In reply to | #399696 |
On 2026-06-04 13:47, Janis Papanagnou wrote: > On 2026-06-04 18:18, Scott Lurndal wrote: >> >> Indeed, and in the early days, the compiler itself would never >> have seen '/*' - the preprocessor (cpp) would have removed it >> from the source before the source reached the first >> pass of the compiler (c0). > > Curious; was the comment-handling at some point in history removed > from the Cpp-processing? - If so, when was that? And I assume the > semantics are still the same; is that correct? That question can only be answered in the context of a particular implementation of C. The C standard defines only what the entire implementation must do when translating and executing a program. Whether all of those tasks are performed by a single program, or whether responsibility for different parts of the process are given to different programs is an implementation detail outside the scope of the C standard. cpp basically implemented translation phases 1-4. cc implemented phases 5-7. The linker implemented phase 8. But those statements are only partially accurate, and other impllementations divided the tasks differently. One advantage of having a single program do the whole thing, is that error messages can mention the actual text of the line where a problem was detected, without any pre-processing applied.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-06-04 14:16 -0700 |
| Message-ID | <10vspuu$lkmu$3@kst.eternal-september.org> |
| In reply to | #399708 |
James Kuyper <jameskuyper@alumni.caltech.edu> writes:
[...]
> One advantage of having a single program do the whole thing, is that
> error messages can mention the actual text of the line where a problem
> was detected, without any pre-processing applied.
Typical preprocessors emit directives that tell the compiler about
the current file name and line number, precisely so that diagnostic
messages can refer to the original text.
For example:
$ cat hello.c
#include <stdio.h>
int main(void) {
printf("Hello world!\n");
}
$ gcc -E hello.c | tail
extern int __uflow (FILE *);
extern int __overflow (FILE *, int);
# 983 "/usr/include/stdio.h" 3 4
# 2 "hello.c" 2
# 2 "hello.c"
int main(void) {
printf("Hello world!\n");
}
$
The line `# 2 "hello.c"` is, according to the C standard, a
"non-directive", which is a kind of directive. Executing a
non-directive has undefined behavior, but gcc apparently treats it
very much like a #line directive.
It doesn't really matter whether the preprocessor is a separate program
or not.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-06-05 00:02 +0000 |
| Message-ID | <10vt3mi$fuu$2@reader1.panix.com> |
| In reply to | #399715 |
In article <10vspuu$lkmu$3@kst.eternal-september.org>,
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>[...]
>> One advantage of having a single program do the whole thing, is that
>> error messages can mention the actual text of the line where a problem
>> was detected, without any pre-processing applied.
>
>Typical preprocessors emit directives that tell the compiler about
>the current file name and line number, precisely so that diagnostic
>messages can refer to the original text.
>
>For example:
>
>$ cat hello.c
>#include <stdio.h>
>int main(void) {
> printf("Hello world!\n");
>}
>$ gcc -E hello.c | tail
>extern int __uflow (FILE *);
>extern int __overflow (FILE *, int);
># 983 "/usr/include/stdio.h" 3 4
>
># 2 "hello.c" 2
>
># 2 "hello.c"
>int main(void) {
> printf("Hello world!\n");
>}
>$
>
>The line `# 2 "hello.c"` is, according to the C standard, a
>"non-directive", which is a kind of directive. Executing a
>non-directive has undefined behavior, but gcc apparently treats it
>very much like a #line directive.
>
>It doesn't really matter whether the preprocessor is a separate program
>or not.
In fairness to Kuyper, however, the *text* from the original
source file is lost. E.g.,
term% cat n.c
#include <stdio.h>
#define FOO "hi"; // Note trailing `;`
int
main(void)
{
printf("%s\n", FOO);
return 0;
}
term% clang -fkeep-system-includes -E n.c
# 1 "n.c"
# 1 "<built-in>" 1
# 1 "<command line>" 1
# 1 "<built-in>" 2
# 1 "n.c" 2
#include <stdio.h> /* clang -E -fkeep-system-includes */
# 1 "n.c"
# 2 "n.c" 2
int
main(void)
{
printf("%s\n", "hi";);
return 0;
}
term%
In this example, the preprocessor macro `FOO` has been lost, and
only its expansion remains. The compiler has no information to
give a useful diagnostic.
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-06-04 18:36 -0700 |
| Message-ID | <10vt97i$pube$1@kst.eternal-september.org> |
| In reply to | #399726 |
cross@spitfire.i.gajendra.net (Dan Cross) writes:
> In article <10vspuu$lkmu$3@kst.eternal-september.org>,
> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>>[...]
>>> One advantage of having a single program do the whole thing, is that
>>> error messages can mention the actual text of the line where a problem
>>> was detected, without any pre-processing applied.
>>
>>Typical preprocessors emit directives that tell the compiler about
>>the current file name and line number, precisely so that diagnostic
>>messages can refer to the original text.
>>
>>For example:
>>
>>$ cat hello.c
>>#include <stdio.h>
>>int main(void) {
>> printf("Hello world!\n");
>>}
>>$ gcc -E hello.c | tail
>>extern int __uflow (FILE *);
>>extern int __overflow (FILE *, int);
>># 983 "/usr/include/stdio.h" 3 4
>>
>># 2 "hello.c" 2
>>
>># 2 "hello.c"
>>int main(void) {
>> printf("Hello world!\n");
>>}
>>$
>>
>>The line `# 2 "hello.c"` is, according to the C standard, a
>>"non-directive", which is a kind of directive. Executing a
>>non-directive has undefined behavior, but gcc apparently treats it
>>very much like a #line directive.
>>
>>It doesn't really matter whether the preprocessor is a separate program
>>or not.
>
> In fairness to Kuyper, however, the *text* from the original
> source file is lost. E.g.,
>
> term% cat n.c
> #include <stdio.h>
> #define FOO "hi"; // Note trailing `;`
> int
> main(void)
> {
> printf("%s\n", FOO);
> return 0;
> }
> term% clang -fkeep-system-includes -E n.c
> # 1 "n.c"
> # 1 "<built-in>" 1
> # 1 "<command line>" 1
> # 1 "<built-in>" 2
> # 1 "n.c" 2
> #include <stdio.h> /* clang -E -fkeep-system-includes */
> # 1 "n.c"
> # 2 "n.c" 2
>
> int
> main(void)
> {
> printf("%s\n", "hi";);
> return 0;
> }
> term%
>
> In this example, the preprocessor macro `FOO` has been lost, and
> only its expansion remains. The compiler has no information to
> give a useful diagnostic.
Ah, but it does, as long as the original file is still there.
$ gcc -c n.c
n.c: In function ‘main’:
n.c:2:17: error: expected ‘)’ before ‘;’ token
2 | #define FOO "hi"; // Note trailing `;`
| ^
n.c:6:20: note: in expansion of macro ‘FOO’
6 | printf("%s\n", FOO);
| ^~~
n.c:6:11: note: to match this ‘(’
6 | printf("%s\n", FOO);
| ^
$
The output of `gcc -E` doesn't include the name FOO, but it does include
the line `# 3 "n.c"`, and that's enough information for the compiler to
open the original source file and copy information from it into an error
message.
(This is perhaps straying slightly off-topic, since the standard
only requires a diagnostic, but it's still interesting to see how
actual compilers do things.)
$ cat n.c
#include <stdio.h>
#define FOO "hi"; // Note trailing `;`
int
main(void)
{
printf("%s\n", FOO);
return 0;
}
$ gcc -E n.c >| n-preprocessed.c
$ grep FOO n-preprocessed.c
$ tail n-preprocessed.c
# 2 "n.c" 2
# 3 "n.c"
int
main(void)
{
printf("%s\n", "hi";);
return 0;
}
$ gcc -c n-preprocessed.c
n.c: In function ‘main’:
n.c:6:24: error: expected ‘)’ before ‘;’ token
6 | printf("%s\n", FOO);
| ~ ^
| )
$
And if I rename n.c before compiling n-preprocessed.c, the error
messages doesn't include that line of code.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-06-05 02:54 +0000 |
| Message-ID | <10vtdon$id4$3@reader1.panix.com> |
| In reply to | #399732 |
In article <10vt97i$pube$1@kst.eternal-september.org>,
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>cross@spitfire.i.gajendra.net (Dan Cross) writes:
>> In article <10vspuu$lkmu$3@kst.eternal-september.org>,
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>>James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>>>[...]
>>>> One advantage of having a single program do the whole thing, is that
>>>> error messages can mention the actual text of the line where a problem
>>>> was detected, without any pre-processing applied.
>>>
>>>Typical preprocessors emit directives that tell the compiler about
>>>the current file name and line number, precisely so that diagnostic
>>>messages can refer to the original text.
>>
>> In fairness to Kuyper, however, the *text* from the original
>> source file is lost. E.g.,
>>
>> term% cat n.c
>> #include <stdio.h>
>> #define FOO "hi"; // Note trailing `;`
>> int
>> main(void)
>> {
>> printf("%s\n", FOO);
>> return 0;
>> }
>> term% clang -fkeep-system-includes -E n.c
>> # 1 "n.c"
>> # 1 "<built-in>" 1
>> # 1 "<command line>" 1
>> # 1 "<built-in>" 2
>> # 1 "n.c" 2
>> #include <stdio.h> /* clang -E -fkeep-system-includes */
>> # 1 "n.c"
>> # 2 "n.c" 2
>>
>> int
>> main(void)
>> {
>> printf("%s\n", "hi";);
>> return 0;
>> }
>> term%
>>
>> In this example, the preprocessor macro `FOO` has been lost, and
>> only its expansion remains. The compiler has no information to
>> give a useful diagnostic.
>
>Ah, but it does, as long as the original file is still there.
Mm, yeah, I suppose, as long as the original is still available.
>$ gcc -c n.c
>n.c: In function ‘main’:
>n.c:2:17: error: expected ‘)’ before ‘;’ token
> 2 | #define FOO "hi"; // Note trailing `;`
> | ^
>n.c:6:20: note: in expansion of macro ‘FOO’
> 6 | printf("%s\n", FOO);
> | ^~~
>n.c:6:11: note: to match this ‘(’
> 6 | printf("%s\n", FOO);
> | ^
>$
>
>The output of `gcc -E` doesn't include the name FOO, but it does include
>the line `# 3 "n.c"`, and that's enough information for the compiler to
>open the original source file and copy information from it into an error
>message.
>
>(This is perhaps straying slightly off-topic, since the standard
>only requires a diagnostic, but it's still interesting to see how
>actual compilers do things.)
>
>$ cat n.c
>#include <stdio.h>
>#define FOO "hi"; // Note trailing `;`
>int
>main(void)
>{
> printf("%s\n", FOO);
> return 0;
>}
>$ gcc -E n.c >| n-preprocessed.c
>$ grep FOO n-preprocessed.c
>$ tail n-preprocessed.c
># 2 "n.c" 2
>
>
># 3 "n.c"
>int
>main(void)
>{
> printf("%s\n", "hi";);
> return 0;
>}
>$ gcc -c n-preprocessed.c
>n.c: In function ‘main’:
>n.c:6:24: error: expected ‘)’ before ‘;’ token
> 6 | printf("%s\n", FOO);
> | ~ ^
> | )
>$
>
>And if I rename n.c before compiling n-preprocessed.c, the error
>messages doesn't include that line of code.
I feel like there is a Stallman joke in there struggling to get
out, but I can't quite get there.
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-06-05 05:49 -0700 |
| Message-ID | <86fr31b18p.fsf@linuxsc.com> |
| In reply to | #399715 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
> [...]
>
>> One advantage of having a single program do the whole thing, is
>> that error messages can mention the actual text of the line where
>> a problem was detected, without any pre-processing applied.
>
> Typical preprocessors emit directives that tell the compiler
> about the current file name and line number, precisely so that
> diagnostic messages can refer to the original text.
>
> For example:
>
> $ cat hello.c
> #include <stdio.h>
> int main(void) {
> printf("Hello world!\n");
> }
> $ gcc -E hello.c | tail
> extern int __uflow (FILE *);
> extern int __overflow (FILE *, int);
> # 983 "/usr/include/stdio.h" 3 4
>
> # 2 "hello.c" 2
>
> # 2 "hello.c"
> int main(void) {
> printf("Hello world!\n");
> }
> $
>
> The line `# 2 "hello.c"` is, according to the C standard, a
> "non-directive", which is a kind of directive. Executing a
> non-directive has undefined behavior,
Since it is gcc that is generating the non-directives, for
internal purposes, and gcc that is consuming them, it hardly
seems worth worrying about whether their behavior is defined
or not.
[toc] | [prev] | [next] | [standalone]
Page 17 of 24 — ← Prev page 1 … 15 16 [17] 18 19 … 24 Next page →
Back to top | Article view | comp.lang.c
csiph-web