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 266 — 20 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 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: 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 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 "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 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: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-04 03:58 -0700
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 10 of 14 — ← Prev page 1 … 8 9 [10] 11 12 … 14 Next page →
| 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 | 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]
| 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]
Page 10 of 14 — ← Prev page 1 … 8 9 [10] 11 12 … 14 Next page →
Back to top | Article view | comp.lang.c
csiph-web