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 385 — 21 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 Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-21 14:26 -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 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 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 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: 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
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") James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-06-11 20:41 -0400
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: 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-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 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 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: 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 16 of 20 — ← Prev page 1 … 14 15 [16] 17 18 … 20 Next page →
| 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]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-06-05 11:01 -0700 |
| Message-ID | <10vv2tk$1aoa2$2@kst.eternal-september.org> |
| In reply to | #399746 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
[...]
>> 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.
I wasn't worried. I just mentioned in in passing.
You quoted most of the article, but snipped relevant context in
the middle of a sentence.
--
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-05 11:53 -0700 |
| Message-ID | <86zf18akfi.fsf@linuxsc.com> |
| In reply to | #399754 |
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: > > [...] > >>> 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. > > I wasn't worried. I just mentioned in in passing. > > You quoted most of the article, but snipped relevant context in > the middle of a sentence. It wasn't relevant to what I wanted to say.
[toc] | [prev] | [next] | [standalone]
| From | Lew Pitcher <lew.pitcher@digitalfreehold.ca> |
|---|---|
| Date | 2026-06-04 18:45 +0000 |
| Message-ID | <10vsh43$b3is$1@dont-email.me> |
| In reply to | #399691 |
On Thu, 04 Jun 2026 16:18:07 +0000, Scott Lurndal wrote:
[snip]
> 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).
So, I've looked through "The C Programming Language" (the K&R C)
and the paper "A Tour Through the Portable C Compiler" (S. C.
Johnson, circa 1974), and neither document states that the
preprocessor strips comments. In fact, the mentions of the
preprocessor are exclusively about the #operation operators,
and not about C comments.
In "A Tour Through the Portable C Compiler", Mr. Johnson explicitly
states that the 1st compiler pass (which follows the preprocessor pass)
takes care of the comments. Specifically, Mr. Johnson says
"Pass 1
The first pass does lexical analysis, parsing, symbol table
maintenance, tree building, optimization, and a number of
machine dependant things. ...
Lexical Analysis
The lexical analyzer is a conceptually simple routine that reads
the input and returns the tokens of the C language as it encounters
them ... The conceptual simplicity of this job is confounded a bit
by several other simple jobs that unfortunately must go on
simultaneously. These include
...
* Skipping comments
"
It appears that, in at least one seminal C compiler, the job of reducing
comments to whitespace was not part of the preprocessor's responsibility
but was instead implemented as part of the first (lexical) pass of the
compiler proper.
--
Lew Pitcher
"In Skills We Trust"
Not LLM output - I'm just like this.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-06-04 20:19 +0000 |
| Message-ID | <10vsmle$4lt$1@reader1.panix.com> |
| In reply to | #399698 |
In article <10vsh43$b3is$1@dont-email.me>, Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote: >On Thu, 04 Jun 2026 16:18:07 +0000, Scott Lurndal wrote: > >[snip] >> 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). > >So, I've looked through "The C Programming Language" (the K&R C) >and the paper "A Tour Through the Portable C Compiler" (S. C. >Johnson, circa 1974), and neither document states that the >preprocessor strips comments. In fact, the mentions of the >preprocessor are exclusively about the #operation operators, >and not about C comments. The PDP-11 compiler from 5th Edition research Unix removes comments in `cc.c`. The 1972 compilers from Dennis Ritchie's web page remove them in the compiler proper, as they predated the preprocessor: https://www.nokia.com/bell-labs/about/dennis-m-ritchie/primevalC.html - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-06-04 20:31 +0000 |
| Message-ID | <sglUR.17897$pxGb.10844@fx07.iad> |
| In reply to | #399706 |
cross@spitfire.i.gajendra.net (Dan Cross) writes:
>In article <10vsh43$b3is$1@dont-email.me>,
>Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
>>On Thu, 04 Jun 2026 16:18:07 +0000, Scott Lurndal wrote:
>>
>>[snip]
>>> 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).
>>
>>So, I've looked through "The C Programming Language" (the K&R C)
>>and the paper "A Tour Through the Portable C Compiler" (S. C.
>>Johnson, circa 1974), and neither document states that the
>>preprocessor strips comments. In fact, the mentions of the
>>preprocessor are exclusively about the #operation operators,
>>and not about C comments.
>
>The PDP-11 compiler from 5th Edition research Unix removes
>comments in `cc.c`. The 1972 compilers from Dennis Ritchie's
>web page remove them in the compiler proper, as they predated
>the preprocessor:
>https://www.nokia.com/bell-labs/about/dennis-m-ritchie/primevalC.html
The v6 cpp.c processes the comments
and deletes them if the 'passcom' (-C) flag is not set.
case '/': for (;;) {
if (*p++=='*') {/* comment */
if (!passcom) {inp=p-2; dump(); ++flslvl;}
for (;;) {
while (!iscom(*p++));
if (p[-1]=='*') for (;;) {
if (*p++=='/') goto endcom;
if (eob(--p)) {
if (!passcom) {inp=p; p=refill(p);}
else if ((p-inp)>=BUFSIZ) {/* split long comment */
inp=p; p=refill(p); /* last char written is '*' */
putc('/',fout); /* terminate first part */
/* and fake start of 2nd */
outp=inp=p-=3; *p++='/'; *p++='*'; *p++='*';
} else p=refill(p);
} else break;
} else if (p[-1]=='\n') {
++lineno[ifno]; if (!passcom) putc('\n',fout);
} else if (eob(--p)) {
if (!passcom) {inp=p; p=refill(p);}
else if ((p-inp)>=BUFSIZ) {/* split long comment */
inp=p; p=refill(p);
putc('*',fout); putc('/',fout);
outp=inp=p-=2; *p++='/'; *p++='*';
} else p=refill(p);
} else ++p; /* ignore null byte */
}
endcom:
if (!passcom) {outp=inp=p; --flslvl; goto again;}
break;
}
if (eob(--p)) p=refill(p);
else break;
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-06-04 20:41 +0000 |
| Message-ID | <10vsnto$ec5$1@reader1.panix.com> |
| In reply to | #399707 |
In article <sglUR.17897$pxGb.10844@fx07.iad>, Scott Lurndal <slp53@pacbell.net> wrote: >cross@spitfire.i.gajendra.net (Dan Cross) writes: >>In article <10vsh43$b3is$1@dont-email.me>, >>Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote: >>>On Thu, 04 Jun 2026 16:18:07 +0000, Scott Lurndal wrote: >>> >>>[snip] >>>> 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). >>> >>>So, I've looked through "The C Programming Language" (the K&R C) >>>and the paper "A Tour Through the Portable C Compiler" (S. C. >>>Johnson, circa 1974), and neither document states that the >>>preprocessor strips comments. In fact, the mentions of the >>>preprocessor are exclusively about the #operation operators, >>>and not about C comments. >> >>The PDP-11 compiler from 5th Edition research Unix removes >>comments in `cc.c`. The 1972 compilers from Dennis Ritchie's >>web page remove them in the compiler proper, as they predated >>the preprocessor: >>https://www.nokia.com/bell-labs/about/dennis-m-ritchie/primevalC.html > >The v6 cpp.c processes the comments >and deletes them if the 'passcom' (-C) flag is not set. > >[snip] You sure? That looks like V7 code to me. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-06-04 20:49 +0000 |
| Message-ID | <8xlUR.17899$pxGb.16870@fx07.iad> |
| In reply to | #399711 |
cross@spitfire.i.gajendra.net (Dan Cross) writes:
>In article <sglUR.17897$pxGb.10844@fx07.iad>,
>Scott Lurndal <slp53@pacbell.net> wrote:
>>cross@spitfire.i.gajendra.net (Dan Cross) writes:
>>>In article <10vsh43$b3is$1@dont-email.me>,
>>>Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
>>>>On Thu, 04 Jun 2026 16:18:07 +0000, Scott Lurndal wrote:
>>>>
>>>>[snip]
>>>>> 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).
>>>>
>>>>So, I've looked through "The C Programming Language" (the K&R C)
>>>>and the paper "A Tour Through the Portable C Compiler" (S. C.
>>>>Johnson, circa 1974), and neither document states that the
>>>>preprocessor strips comments. In fact, the mentions of the
>>>>preprocessor are exclusively about the #operation operators,
>>>>and not about C comments.
>>>
>>>The PDP-11 compiler from 5th Edition research Unix removes
>>>comments in `cc.c`. The 1972 compilers from Dennis Ritchie's
>>>web page remove them in the compiler proper, as they predated
>>>the preprocessor:
>>>https://www.nokia.com/bell-labs/about/dennis-m-ritchie/primevalC.html
>>
>>The v6 cpp.c processes the comments
>>and deletes them if the 'passcom' (-C) flag is not set.
>>
>>[snip]
>
>You sure? That looks like V7 code to me.
Yes, it is. I didn't have a machine readable version of the
v6 compiler handy. Dug it out and here's the v6 version.
getch()
{
register int c, lastst;
while ((c=getc1())=='/' && !instring)
{
if ((c=getc1())!='*')
{
pushback(c);
return('/');
}
if (!skipcom)
{putc('/',fout); putc('*', fout);}
lastst=0;
while ( (c = getc1()) != '\0')
{
if (lastst && c=='/')
{
if (!skipcom)
putc('/', fout);
break;
}
if (c=='\n' || !skipcom)
putc(c, fout);
lastst = (c=='*');
}
if (c=='\0')break;
}
return(c);
}
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-06-05 00:03 +0000 |
| Message-ID | <10vt3nv$fuu$3@reader1.panix.com> |
| In reply to | #399712 |
In article <8xlUR.17899$pxGb.16870@fx07.iad>,
Scott Lurndal <slp53@pacbell.net> wrote:
>cross@spitfire.i.gajendra.net (Dan Cross) writes:
>>In article <sglUR.17897$pxGb.10844@fx07.iad>,
>>Scott Lurndal <slp53@pacbell.net> wrote:
>>>cross@spitfire.i.gajendra.net (Dan Cross) writes:
>>>>In article <10vsh43$b3is$1@dont-email.me>,
>>>>Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
>>>>>On Thu, 04 Jun 2026 16:18:07 +0000, Scott Lurndal wrote:
>>>>>
>>>>>[snip]
>>>>>> 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).
>>>>>
>>>>>So, I've looked through "The C Programming Language" (the K&R C)
>>>>>and the paper "A Tour Through the Portable C Compiler" (S. C.
>>>>>Johnson, circa 1974), and neither document states that the
>>>>>preprocessor strips comments. In fact, the mentions of the
>>>>>preprocessor are exclusively about the #operation operators,
>>>>>and not about C comments.
>>>>
>>>>The PDP-11 compiler from 5th Edition research Unix removes
>>>>comments in `cc.c`. The 1972 compilers from Dennis Ritchie's
>>>>web page remove them in the compiler proper, as they predated
>>>>the preprocessor:
>>>>https://www.nokia.com/bell-labs/about/dennis-m-ritchie/primevalC.html
>>>
>>>The v6 cpp.c processes the comments
>>>and deletes them if the 'passcom' (-C) flag is not set.
>>>
>>>[snip]
>>
>>You sure? That looks like V7 code to me.
>
>Yes, it is. I didn't have a machine readable version of the
>v6 compiler handy. Dug it out and here's the v6 version.
>
>
>getch()
>{
> register int c, lastst;
>
> while ((c=getc1())=='/' && !instring)
> {
> if ((c=getc1())!='*')
> {
> pushback(c);
> return('/');
> }
> if (!skipcom)
> {putc('/',fout); putc('*', fout);}
> lastst=0;
> while ( (c = getc1()) != '\0')
> {
> if (lastst && c=='/')
> {
> if (!skipcom)
> putc('/', fout);
> break;
> }
> if (c=='\n' || !skipcom)
> putc(c, fout);
> lastst = (c=='*');
> }
> if (c=='\0')break;
> }
> return(c);
>}
Yeah, that's from `cc.c`, right?
I think 7th Ed was the first where `cpp` was liberated from the
compiler proper (or the driver, anyway).
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-06-05 00:18 +0000 |
| Message-ID | <1BoUR.3$lmCb.1@fx22.iad> |
| In reply to | #399727 |
cross@spitfire.i.gajendra.net (Dan Cross) writes:
>In article <8xlUR.17899$pxGb.16870@fx07.iad>,
>Scott Lurndal <slp53@pacbell.net> wrote:
>>cross@spitfire.i.gajendra.net (Dan Cross) writes:
>>>In article <sglUR.17897$pxGb.10844@fx07.iad>,
>>>Scott Lurndal <slp53@pacbell.net> wrote:
>>>>cross@spitfire.i.gajendra.net (Dan Cross) writes:
>>>>>In article <10vsh43$b3is$1@dont-email.me>,
>>>>>Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
>>>>>>On Thu, 04 Jun 2026 16:18:07 +0000, Scott Lurndal wrote:
>>>>>>
>>>>>>[snip]
>>>>>>> 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).
>>>>>>
>>>>>>So, I've looked through "The C Programming Language" (the K&R C)
>>>>>>and the paper "A Tour Through the Portable C Compiler" (S. C.
>>>>>>Johnson, circa 1974), and neither document states that the
>>>>>>preprocessor strips comments. In fact, the mentions of the
>>>>>>preprocessor are exclusively about the #operation operators,
>>>>>>and not about C comments.
>>>>>
>>>>>The PDP-11 compiler from 5th Edition research Unix removes
>>>>>comments in `cc.c`. The 1972 compilers from Dennis Ritchie's
>>>>>web page remove them in the compiler proper, as they predated
>>>>>the preprocessor:
>>>>>https://www.nokia.com/bell-labs/about/dennis-m-ritchie/primevalC.html
>>>>
>>>>The v6 cpp.c processes the comments
>>>>and deletes them if the 'passcom' (-C) flag is not set.
>>>>
>>>>[snip]
>>>
>>>You sure? That looks like V7 code to me.
>>
>>Yes, it is. I didn't have a machine readable version of the
>>v6 compiler handy. Dug it out and here's the v6 version.
>>
>>
>>getch()
>>{
>> register int c, lastst;
>>
>> while ((c=getc1())=='/' && !instring)
>> {
>> if ((c=getc1())!='*')
>> {
>> pushback(c);
>> return('/');
>> }
>> if (!skipcom)
>> {putc('/',fout); putc('*', fout);}
>> lastst=0;
>> while ( (c = getc1()) != '\0')
>> {
>> if (lastst && c=='/')
>> {
>> if (!skipcom)
>> putc('/', fout);
>> break;
>> }
>> if (c=='\n' || !skipcom)
>> putc(c, fout);
>> lastst = (c=='*');
>> }
>> if (c=='\0')break;
>> }
>> return(c);
>>}
>
>Yeah, that's from `cc.c`, right?
No, it's from cpp.c
$ ls /work/reference/collegetapes/sltape/v6cc/
c0.c c00.c c01.c c02.c c03.c c04.c c05.c c1.h
c10.c c11.c c12.c c13.c c2.h c20.c c21.c cc.c cpp.c
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-06-05 03:02 +0000 |
| Message-ID | <10vte7f$id4$4@reader1.panix.com> |
| In reply to | #399728 |
In article <1BoUR.3$lmCb.1@fx22.iad>, Scott Lurndal <slp53@pacbell.net> wrote:
>cross@spitfire.i.gajendra.net (Dan Cross) writes:
>>[snip]
>>>getch()
>>>{
>>> register int c, lastst;
>>>
>>> while ((c=getc1())=='/' && !instring)
>>> {
>>> if ((c=getc1())!='*')
>>> {
>>> pushback(c);
>>> return('/');
>>> }
>>> if (!skipcom)
>>> {putc('/',fout); putc('*', fout);}
>>> lastst=0;
>>> while ( (c = getc1()) != '\0')
>>> {
>>> if (lastst && c=='/')
>>> {
>>> if (!skipcom)
>>> putc('/', fout);
>>> break;
>>> }
>>> if (c=='\n' || !skipcom)
>>> putc(c, fout);
>>> lastst = (c=='*');
>>> }
>>> if (c=='\0')break;
>>> }
>>> return(c);
>>>}
>>
>>Yeah, that's from `cc.c`, right?
>
>No, it's from cpp.c
>
>$ ls /work/reference/collegetapes/sltape/v6cc/
>c0.c c00.c c01.c c02.c c03.c c04.c c05.c c1.h
>c10.c c11.c c12.c c13.c c2.h c20.c c21.c cc.c cpp.c
Oh interesting. I don't have a `cpp.c` in my v6 archive.
I wonder what else I'm missing.
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-06-05 14:04 +0000 |
| Message-ID | <DHAUR.47540$0o1c.29921@fx08.iad> |
| In reply to | #399736 |
cross@spitfire.i.gajendra.net (Dan Cross) writes:
>In article <1BoUR.3$lmCb.1@fx22.iad>, Scott Lurndal <slp53@pacbell.net> wrote:
>>cross@spitfire.i.gajendra.net (Dan Cross) writes:
>>>[snip]
<snip>
>>>Yeah, that's from `cc.c`, right?
>>
>>No, it's from cpp.c
>>
>>$ ls /work/reference/collegetapes/sltape/v6cc/
>>c0.c c00.c c01.c c02.c c03.c c04.c c05.c c1.h
>>c10.c c11.c c12.c c13.c c2.h c20.c c21.c cc.c cpp.c
>
>Oh interesting. I don't have a `cpp.c` in my v6 archive.
>
>I wonder what else I'm missing.
For your archive, cpp.c
#
# include <stdio.h>
/* C command */
# define SBSIZE 15000
# define SYMSIZ 1500
# define TOKLEN 16
# define DROP (-2)
# define SAME 0
# define MAXINC 10
char sbf[SBSIZE];
# define CHSPACE 1000
char ts[CHSPACE+50];
# define EXPSIZE 500
char *strdex(), *copy(), *calloc(), *token(), *coptok();
char *tsa ts;
char *tsp ts;
char *fnames[MAXINC];
# define LINELEN 512
FILE *fin;
FILE *fout;
int instring;
char direct[50];
int nd 1;
char *dirs[10] {direct, 0};
char nfil[100];
int pflag;
int depth;
int skipcom;
FILE *fins[MAXINC];
int ifno;
char *lp;
char *line;
# define NPREDEF 20
char *prespc[NPREDEF];
char **predef prespc;
char *punspc[NPREDEF];
char **prund punspc;
char **predp;
int lineno[MAXINC];
int exfail;
struct symtab {
char name[TOKLEN];
char *value;
} *symtab, *lookup();
struct symtab *defloc;
struct symtab *udfloc;
struct symtab *incloc;
struct symtab *ifloc;
struct symtab *elsloc;
struct symtab *eifloc;
struct symtab *ifdloc;
struct symtab *ifnloc;
struct symtab *sysloc;
struct symtab *lneloc;
struct symtab *prdloc;
int trulvl;
int flslvl;
char *stringbuf;
mainpp(argc,argv)
char *argv[];
{
int i;
# ifdef tgp
int ifbrk;
# endif
char ln[LINELEN];
register int c;
register char *rlp;
char *sp;
struct symtab stab[SYMSIZ];
fin = stdin;
fout = stdout;
# ifdef unix
fnames[ifno=0] = "";
# endif
# ifdef gcos
fnames[ifno=0] = "s*";
# endif
# ifdef ibm
fnames[ifno=0] = "";
# endif
for(i=1; i<argc; i++)
{
switch(argv[i][0])
{
case '-':
switch(argv[i][1])
{
case 'P':
pflag++;
case 'E':
continue;
case 'D':
if (predef>prespc+NPREDEF)
{
error("too many -D options, ignoring %s",argv[i]);
continue;
}
*predef++ = argv[i]+2;
continue;
case 'U':
if (prund>punspc+NPREDEF)
{
error("too many -U options, ignoring %s",argv[i]);
continue;
}
*prund++ = argv[i]+2;
continue;
case 'I':
if (nd>8)
error("excessive -I file (%s) ignored",argv[i]);
else
dirs[nd++] = argv[i]+2;
continue;
case '\0': continue;
default:
error("unknown flag %s", argv[i]);
continue;
}
default:
if (fin==stdin)
{
fin = fopen(argv[i], "r");
if (fin==NULL)
{
error("No source file %s",argv[i]);
exit(8);
}
fnames[ifno]=argv[i];
strcpy(direct, argv[i]);
for(sp=direct; *sp; sp++);
while (sp>direct && *sp != '/') sp--;
# ifdef unix
if (sp==direct)
*sp++ = '.';
# endif
*sp=0; /* direct now has place where source file is */
}
else
if (fout==stdout)
{
fout= fopen(argv[i], "w");
if (fout==NULL)
{
error("Can't write %s", argv[i]);
exit(8);
}
}
else
error("extraneous name %s", argv[i]);
}
}
fins[ifno]=fin;
exfail = 0;
/* after user -I files here are the standard include libraries */
# ifdef unix
dirs[nd++] = "/usr/include";
# endif
# ifdef gcos
dirs[nd++] = "cc";
# endif
# ifdef ibm
dirs[nd++] = "stdio.";
# endif
/* dirs[nd++] = "/compool"; */
dirs[nd++] = 0;
symtab = stab;
for (c=0; c<SYMSIZ; c++) {
stab[c].name[0] = '\0';
stab[c].value = 0;
}
insym(&defloc, "define");
insym(&udfloc, "undef");
insym(&incloc, "include");
insym(&elsloc, "else");
insym(&eifloc, "endif");
insym(&ifdloc, "ifdef");
insym(&ifnloc, "ifndef");
insym(&ifloc, "if");
# ifdef unix
insym(&sysloc, "unix");
# endif
# ifdef gcos
insym (&sysloc, "gcos");
# endif
# ifdef ibm
insym (&sysloc, "ibm");
# endif
insym(&lneloc, "line");
predp=predef;
while (predp>prespc)
if (sp=strdex(*--predp, '='))
{
*sp++=0;
stsym(*predp, sp);
}
else
insym(&prdloc, *predp);
predp=prund;
while (predp>punspc)
{
if (sp=strdex(*--predp, '='))
*sp++=0;
lookup(*predp, DROP);
}
stringbuf = sbf;
trulvl = 0;
flslvl = 0;
line = ln;
lineno[0] = 1;
if (pflag==0) fprintf(fout, "# 1 \"%s\"\n", fnames[ifno]);
while(getline()) {
skipcom=0;
if (ln[0] != '#' && flslvl==0)
{
# ifdef tgp
ifbrk= checklen(line);
# endif
for (rlp = line; c = *rlp++;)
putc(c, fout);
# ifdef tgp
if (ifbrk)
fprintf(fout,"\n# %d",lineno[ifno]);
# endif
}
putc('\n', fout);
}
# ifdef tgp
checklen(line);
# endif
for(rlp=line; c = *rlp++;)
putc(c,fout);
}
getline()
{
register int c, sc, state;
struct symtab *np;
char *namep, *filname, **dirp;
int filok, inctype;
lp = line;
*lp = '\0';
state = 0;
if ((c=getch()) == '#')
state = 1;
while (c!='\n' && c!='\0') {
if (letter(c)) {
namep = lp;
sch(c);
while (letnum(c=getch()))
sch(c);
sch('\0');
lp--;
if (state==6)
{
lookup(namep, DROP);
goto out;
}
if (state>3 && state <6) {
if (flslvl==0 &&(state+!lookup(namep,-1)->name[0])==5)
trulvl++;
else
flslvl++;
out:
while (c!='\n' && c!= '\0')
c = getch();
return(c);
}
if (state==3) /* include */
if (*namep != '"' && *namep != '<')
{
error("Bad include syntax", 0);
state=1;
}
if (state!=2 || flslvl==0)
{
pushback(c);
np = lookup(namep, state);
c = getch();
}
if (state==1) {
if (np==defloc)
skipcom = state = 2;
else if (np==incloc)
state = 3;
else if (np==ifnloc)
state = 4;
else if (np==ifdloc)
state = 5;
else if (np==eifloc) {
if (flslvl)
--flslvl;
else if (trulvl)
--trulvl;
else errback("If-less endif",0);
goto out;
}
else if (np==elsloc) {
if (flslvl)
--flslvl? ++flslvl : ++trulvl;
else if (trulvl)
{++flslvl; --trulvl;}
else
errback("If-less else",0);
goto out;
}
else if (np==udfloc) {
state=6;
}
else if (np==ifloc) {
/*
if (flslvl ==0 && yyparse())
*/ error("IF not implemented, true assumed",0); if (1)
trulvl++;
else
flslvl++;
return('\n');
}
else if (np==lneloc)
{
if(pflag==0) fprintf(fout, "# ");
lp=line;
for(; c !='\n' && c != '\0'; c=getch())
if (!pflag)
sch(c);
sch('\0');
return(c);
}
else {
errback("Undefined control",0);
while (c!='\n' && c!='\0')
c = getch();
return(c);
}
} else if (state==2) {
if (flslvl)
goto out;
np->value = stringbuf;
if (c != '\n' && c != 0)
{
savch(c);
while ((c=getch())!='\n' && c!='\0')
{
if (c== '\\')
{
c = getch();
if (c=='\n')continue;
savch('\\');
}
savch(c);
}
}
savch('\0');
return(1);
}
continue;
} else if ((sc=c) == '\'' || sc== '"' || (state==3 && sc== '<')) {
sch(sc);
filname = lp;
inctype = sc=='<';
if (sc== '<')
{
/*
fprintf(fout==stdout?stderr:stdout, "note: include <> obsolete, use \"\"\n");
*/
sc= '>';
}
instring++;
while ((c=getch())!=sc && c!='\n' && c!='\0') {
sch(c);
if (c=='\\')
sch(getch());
}
instring = 0;
if (flslvl)
goto out;
if (state==3) {
if (flslvl)
goto out;
*lp = '\0';
while ((c=getch())!='\n' && c!='\0');
if (ifno+1 >=MAXINC)
error("Unreasonable include nesting",0);
filok=0;
for(dirp=dirs+inctype; *dirp; dirp++)
{
if (filname[0]=='/' || **dirp=='\0')
strcpy(nfil,filname);
else
{
strcpy(nfil,*dirp);
# ifdef unix
strcat(nfil, "/");
# endif
# ifdef gcos
strcat(nfil, "/");
# endif
# ifdef ibm
strcat(nfil, ".");
# endif
strcat(nfil, filname);
}
if ( (fins[ifno+1]=fopen(nfil, "r"))!=NULL)
{
filok=1;
fin = fins[++ifno];
break;
}
}
if (filok==0)
errback("Can't find include file %s", filname);
else
{
if (pflag==0) fprintf(fout, "\n# 1 \"%s\"", filname);
lineno[ifno]=1;
fnames[ifno] = copy(filname);
}
return(c);
}
}
sch(sc=c);
c = getch();
if (isdigit(sc))
{
for (;isalpha(c) || isdigit(c); c=getch())
sch(c);
}
}
sch('\0');
if (state>1)
errback("Control syntax",0);
return(c);
}
insym(sp, namep)
struct symtab **sp;
char *namep;
{
register struct symtab *np;
*sp = np = lookup(namep, 1);
np -> value = np -> name;
}
stsym(namep, valp)
char *namep, *valp;
{
register struct symtab *np;
np = lookup(namep, 1);
np->value = valp;
}
error(s, x)
char *s;
{
FILE *efout;
efout = fout==stdout ? stderr : stdout;
if (fnames[ifno][0])
fprintf(efout,"%s: %d: ", fnames[ifno], lineno[ifno]);
fprintf(efout, s, x);
putc('\n',efout);
exfail++;
}
errback(s,x)
char *s;
{
lineno[ifno]--;
error(s,x);
lineno[ifno]++;
}
sch(c)
{
register char *rlp;
rlp = lp;
if (rlp==line+LINELEN-2)
error("Line overflow", 0);
*rlp++ = c;
if (rlp>line+LINELEN-1)
rlp = line+LINELEN-1;
lp = rlp;
}
savch(c)
{
*stringbuf++ = c;
if (stringbuf-sbf < SBSIZE)
return;
error("Too much defining", 0);
exit(exfail);
}
getch()
{
register int c, lastst;
while ((c=getc1())=='/' && !instring)
{
if ((c=getc1())!='*')
{
pushback(c);
return('/');
}
if (!skipcom)
{putc('/',fout); putc('*', fout);}
lastst=0;
while ( (c = getc1()) != '\0')
{
if (lastst && c=='/')
{
if (!skipcom)
putc('/', fout);
break;
}
if (c=='\n' || !skipcom)
putc(c, fout);
lastst = (c=='*');
}
if (c=='\0')break;
}
return(c);
}
char pushbuff[EXPSIZE];
char *pushp pushbuff;
pushback(c)
{
*++pushp = c;
if (pushp>pushbuff+EXPSIZE) {
error("too much backup", 0);
exit(8);
}
}
getc1()
{
register c;
if (*pushp !=0)
return(*pushp--);
depth=0;
if ((c = getc(fin)) == EOF && ifno>0) {
fclose(fin);
fin = fins[--ifno];
if (pflag==0) fprintf(fout, "\n# %d \"%s\"\n",lineno[ifno], fnames[ifno]);
c = getc1();
if (c=='\n') lineno[ifno]--;
}
if (c==EOF)
return(0);
if (c=='\n' )
lineno[ifno]++;
return(c);
}
struct symtab *
lookup(namep, enterf)
char *namep;
{
register char *np, *snp;
register struct symtab *sp;
int i, c, around;
np = namep;
snp = np+TOKLEN;
around = i = 0;
while ( (c = *np++ ) && (np-snp)<0)
{
i =+ c;
}
i =% SYMSIZ;
sp = &symtab[i];
while (sp->name[0]) {
if (sp->name[0] != DROP)
{
snp = sp->name;
np = namep;
while (*snp++ == *np)
if (*np++ == '\0' || np==namep+TOKLEN) {
if (enterf==DROP)
{
sp->name[0]= DROP;
return(sp);
}
if (!enterf)
subst(namep, sp);
return(sp);
}
}
if (++sp >= &symtab[SYMSIZ])
if (around++)
{
error("too many defines", 0);
exit(exfail);
}
else
sp = symtab;
}
if (enterf>0) {
snp = namep;
for (np = &sp->name[0]; np < &sp->name[TOKLEN];)
if (*np++ = *snp)
snp++;
}
return(sp);
}
char revbuff[200], *bp;
backsch(c)
{
if (bp-revbuff > 200)
error("Excessive define looping", bp--);
*bp++ = c;
}
subst(np, sp)
char *np;
struct symtab *sp;
{
register char *vp;
int macflg;
lp = np;
bp = revbuff;
if (depth++>100)
{
error("define recursion loop on %s", np);
return;
}
if ((vp = sp->value) == 0)
return;
macflg= (*vp == '(');
/* arrange that define unix unix still
has no effect, avoiding rescanning */
while (blank(*vp))
vp++;
if (strcmp(sp->name,vp) == SAME)
{
while (*vp)
sch(*vp++);
return;
}
if (macflg)
expdef(vp);
else
while (*vp)
backsch(*vp++);
while (bp>revbuff)
pushback(*--bp);
}
char *
copy(as)
char as[];
{
register char *otsp, *s;
int i;
otsp = tsp;
s = as;
while(*tsp++ = *s++);
if (tsp >tsa+CHSPACE)
{
# ifdef unix
tsp = tsa = i = calloc(CHSPACE+50,sizeof(char));
if (i== NULL)
# endif
{
error("no space for file names", 0);
exit(8);
}
}
return(otsp);
}
expdef(proto)
char *proto;
{
char buffer[EXPSIZE], *parg[20], *pval[20], name[20], *cspace, *wp;
char protcop[EXPSIZE], *pr;
int narg, k, c;
pr = protcop;
while (*pr++ = *proto++)
if (pr>=protcop+EXPSIZE){
error("define prototype too big", 0);
exit(8);
}
proto= protcop;
for (narg=0; (parg[narg] = token(&proto)) != 0; narg++)
;
/* now scan input */
cspace = buffer;
while ((c=getch()) == ' ');
if (c != '(')
{
error("defined function requires arguments", 0);
return;
}
pushback(c);
for(k=0; pval[k] = coptok(&cspace, buffer+EXPSIZE); k++);
if (k!=narg)
{
error("define argument mismatch");
return;
}
while (c= *proto++)
{
if (!letter(c))
backsch(c);
else
{
wp = name;
*wp++ = c;
while (letnum(*proto))
*wp++ = *proto++;
*wp = 0;
for (k=0; k<narg; k++)
if(strcmp(name,parg[k]) == SAME)
break;
wp = k <narg ? pval[k] : name;
while (*wp) backsch(*wp++);
}
}
}
char *
token(cpp) char **cpp;
{
char *val;
int stc;
stc = **cpp;
*(*cpp)++ = '\0';
if (stc==')') return(0);
while (**cpp == ' ') (*cpp)++;
for (val = *cpp; (stc= **cpp) != ',' && stc!= ')'; (*cpp)++)
{
if (!letnum(stc) || (val == *cpp && !letter(stc)))
{
error("define prototype argument error");
return(0);
}
}
return(val);
}
char *
coptok (cpp, clim) char **cpp, *clim;
{
char *val;
int stc, stop,paren;
paren = stop = 0;
val = *cpp;
if (getch() == ')')
return(0);
while (((stc = getch()) != ',' && stc != ')' ) || paren > 0 || stop >0)
{
if (stc == '\0')
{
error("non terminated macro call", 0);
val = 0;
break;
}
if (stop == 0 && (stc == '"' || stc == '\''))
stop = stc;
else if (stc==stop)
stop=0;
if ( stc == '\\')
{
stc = getch();
if (stop>0 || (stc != ',' && stc != '\\'))
*(*cpp)++ = '\\';
*(*cpp)++ = stc;
}
else
{
*(*cpp)++ = stc;
if (stop==0)
{
if (stc == '(')
paren++;
if (stc == ')')
paren--;
}
}
if (*cpp >= clim)
{
error("define argument too long",0);
exit(8);
}
}
*(*cpp)++ = 0;
pushback(stc);
return(val);
}
letter(c)
{
if (isalpha(c) || c == '_')
return (1);
else
return(0);
}
letnum(c)
{
if (letter(c) || isdigit(c))
return(1);
else
return(0);
}
blank(c)
{
return(c==' ' || c== '\t');
}
char *
strdex(s,c)
char *s;
{
while (*s)
if (*s==c)
return(s);
else
s++;
return(0);
}
# ifdef tgp
# define MAXOUT 80
checklen(sln)
char *sln;
{
/* for tgp: scans string sln, and puts in newlines for blanks,
where it likes, but to make lines less than MAXOUT chars long */
char *p, *s, *st;
int stopc, back, ifdone, c;
st=s=sln;
ifdone=p=stopc=back=0;
while (c= *s++)
{
if (c == '\\')
back=2;
if (back==0)
{
if (stopc== c)
stopc=0;
else
if (c == '"' || c == '\'')
stopc= c;
}
if (back>0)back--;
if (s-st >MAXOUT && p != 0)
{
st=p;
*p= '\n';
ifdone=1;
}
if (stopc==0 && back==0)
if (c==' ') p=s-1;;
}
return(ifdone);
}
# endif
main(argc,argv) char *argv[]; {
exit(mainpp (argc,argv) );
}
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-06-06 03:49 +0000 |
| Message-ID | <11005ca$gc8$3@reader1.panix.com> |
| In reply to | #399750 |
In article <DHAUR.47540$0o1c.29921@fx08.iad>, Scott Lurndal <slp53@pacbell.net> wrote: >cross@spitfire.i.gajendra.net (Dan Cross) writes: >>In article <1BoUR.3$lmCb.1@fx22.iad>, Scott Lurndal <slp53@pacbell.net> wrote: >>>cross@spitfire.i.gajendra.net (Dan Cross) writes: >>>>[snip] > <snip> >>>>Yeah, that's from `cc.c`, right? >>> >>>No, it's from cpp.c >>> >>>$ ls /work/reference/collegetapes/sltape/v6cc/ >>>c0.c c00.c c01.c c02.c c03.c c04.c c05.c c1.h >>>c10.c c11.c c12.c c13.c c2.h c20.c c21.c cc.c cpp.c >> >>Oh interesting. I don't have a `cpp.c` in my v6 archive. >> >>I wonder what else I'm missing. > > [snip] Thanks! This is an artifact definitely worth preserving. As far as I know, it's not in any of the extant V6 archives. I'll shoot you an email, if that's ok. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-06-06 15:13 +0000 |
| Message-ID | <uOWUR.178488$DvK9.138773@fx48.iad> |
| In reply to | #399764 |
cross@spitfire.i.gajendra.net (Dan Cross) writes: >In article <DHAUR.47540$0o1c.29921@fx08.iad>, >Scott Lurndal <slp53@pacbell.net> wrote: >>cross@spitfire.i.gajendra.net (Dan Cross) writes: >>>In article <1BoUR.3$lmCb.1@fx22.iad>, Scott Lurndal <slp53@pacbell.net> wrote: >>>>cross@spitfire.i.gajendra.net (Dan Cross) writes: >>>>>[snip] >> <snip> >>>>>Yeah, that's from `cc.c`, right? >>>> >>>>No, it's from cpp.c >>>> >>>>$ ls /work/reference/collegetapes/sltape/v6cc/ >>>>c0.c c00.c c01.c c02.c c03.c c04.c c05.c c1.h >>>>c10.c c11.c c12.c c13.c c2.h c20.c c21.c cc.c cpp.c >>> >>>Oh interesting. I don't have a `cpp.c` in my v6 archive. >>> >>>I wonder what else I'm missing. >> >> [snip] > >Thanks! This is an artifact definitely worth preserving. As >far as I know, it's not in any of the extant V6 archives. I'll >shoot you an email, if that's ok. > > - Dan C. >
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-06-06 17:53 +0000 |
| Message-ID | <18ZUR.498853$u0G1.241809@fx01.iad> |
| In reply to | #399764 |
cross@spitfire.i.gajendra.net (Dan Cross) writes: >In article <DHAUR.47540$0o1c.29921@fx08.iad>, >Scott Lurndal <slp53@pacbell.net> wrote: >>cross@spitfire.i.gajendra.net (Dan Cross) writes: >>>In article <1BoUR.3$lmCb.1@fx22.iad>, Scott Lurndal <slp53@pacbell.net> wrote: >>>>cross@spitfire.i.gajendra.net (Dan Cross) writes: >>>>>[snip] >> <snip> >>>>>Yeah, that's from `cc.c`, right? >>>> >>>>No, it's from cpp.c >>>> >>>>$ ls /work/reference/collegetapes/sltape/v6cc/ >>>>c0.c c00.c c01.c c02.c c03.c c04.c c05.c c1.h >>>>c10.c c11.c c12.c c13.c c2.h c20.c c21.c cc.c cpp.c >>> >>>Oh interesting. I don't have a `cpp.c` in my v6 archive. >>> >>>I wonder what else I'm missing. >> >> [snip] > >Thanks! This is an artifact definitely worth preserving. As >far as I know, it's not in any of the extant V6 archives. I'll >shoot you an email, if that's ok. A a version of cpp that was used with the portable C compiler (PCC) is here. It has a -C option to preserve comments in the processed output. https://github.com/IanHarvey/pcc/blob/master/cc/cpp/cpp.c
[toc] | [prev] | [next] | [standalone]
Page 16 of 20 — ← Prev page 1 … 14 15 [16] 17 18 … 20 Next page →
Back to top | Article view | comp.lang.c
csiph-web