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 256 — 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 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 "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 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 "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 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 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 13 — ← Prev page 1 … 8 9 [10] 11 12 13 Next page →
| 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 | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-06-04 11:59 -0700 |
| Message-ID | <10vshv6$ipkn$1@kst.eternal-september.org> |
| In reply to | #399682 |
Bart <bc@freeuk.com> writes:
> On 04/06/2026 13:35, David Brown wrote:
>> On 04/06/2026 13:40, Bart wrote:
>>> On 04/06/2026 10:34, Tim Rentsch wrote:
>>>> Bart <bc@freeuk.com> writes:
>>>
>>>>> My point was that it could be objective, at least for too many. So
>>>>> (a*a) + (b*b) would be commonly agreed to have too many, [...]
>>>>
>>>> Apparently you misunderstand what is meant by the word objective.
>>>> An objective statement is one that is independent of personal
>>>> assessment, even collective personal assessment.
>>>
>>> I don't know of any infix PL syntax where 'a*a + b*b', as a
>>> standalone expression, doesn't mean '(a*a) + (b*b)'.
>>>
>>> Google agrees with me (in that 2*2+3*3 shows 13), and so does my
>>> Casio calculator.
>>>
>>> It's not my personal opinion!
>> You are - again - moving the goalposts.
>> It is an objective fact that "a * a + b * b" means "(a * a) + (b *
>> b)" in normal mathematics (at least in the countries I am familiar
>> with), and also in most mainstream programming languages.
>> It is an objective fact, therefore, that "(a*a) + (b*b)" has more
>> parentheses than needed in the context of most programming
>> languages.
>> "(a*a) + (b*b) has too many parentheses", on the other hand, is a
>> purely subjective opinion.
>
> So, you're arguing 'more than needed' is a completely different thing
> from 'too many'.
>
> Sigh...
Yes, it's a different thing, assuming at least one reasonable
interpretation of "more than needed". But if you use the phrase
"more than needed" without specifying *for what purpose*, you have
ammunition for a long pointless argument.
`(a*a) + (b*b)` objectively has more parentheses than are needed
*for the purpose of telling the compiler which operations go with
which operands*. Assuming it's a full expression, it's exactly
equivalent to `a*a + b*b`.
My subjective opinion is that `(a*a) + (b*b)` has "too many"
parentheses. The relative precedences of "*" and "+" are
sufficiently well known that I find the parentheses distracting.
A subjective opinion doesn't become objective just because almost
everyone agrees with it.
Even the idea that "*" should bind more tightly than "+" is
subjective. It's a rule that only goes back to the 1600s or so.
Mathematicians *invented* it. There are real advantages to that
choice, and *tremendous* advantages to having a near-universal
convention, but for example strict left-to-right association would
also have been a valid choice. (And implementing an expression
parser that binds "+" more tightly than "*" could be an interesting
exercise, though few would want to use it in practice.) Again, a
subjective preference doesn't become objective just because nearly
everyone agrees with it.
On the other hand, if I'm explaining the precedence rules, I might
say (as I did above) that `a*a + b*b` is equivalent to `(a*a) + (b*b)`.
In that context the parentheses are not "too many"; they're a
necessary part of the explanation. I find them to be "too many"
for the purpose of writing clear code, but not for some more
specialized purposes.
>> If you wrote, for example, that "a << b + c" is ambiguous in C, then
>> you
>
> It is technically unambiguous in C. It can be ambiguous in the mind of
> somebody who would have to double-check the precedence levels, or
> where the C context is missing.
Agreed.
> The discssion seems to about what exactly is 'too many'.
If so, then we need to be clear what "too many" means. Too many
for what purpose?
> Apparently you can constuct a valid C source file where 99.9% of the
> text consists of () characters, but if someone - or even a million
> people - say that it is too many, then that is just their subjective
> opinion.
(((((((((((((((a))))))))))))))), without any more context, is likely
to be "too many" parentheses. If it's the result of a complicated
macro expansion or machine-generated code, it might not matter.
If the purpose is to test what depth of parentheses a compiler
supports without crashing, it's probably not nearly enough.
> I don't have the patience for such nonsense any more:
>
> * The () in '(a * b) + c' are generally unnecessary
>
> * The () in 'a << (b + c)' are advisable
>
> * The () in '(a << b) + c)' are necessary if the intent is to have
> what might be the more intuitive meaning.
I agree on all three points (apart from the mismatched ")" in the
last one).
[...]
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-06-04 15:21 +0200 |
| Message-ID | <10vru4j$2bg8$2@dont-email.me> |
| In reply to | #399680 |
In your post you already addressed a lot that I'd have written as well (more or less). On 2026-06-04 14:35, David Brown wrote: > On 04/06/2026 13:40, Bart wrote: >> [...] [...] > > It is an objective fact that "a * a + b * b" means "(a * a) + (b * b)" > in normal mathematics (at least in the countries I am familiar with), > and also in most mainstream programming languages. > > It is an objective fact, therefore, that "(a*a) + (b*b)" has more > parentheses than needed in the context of most programming languages. > > "(a*a) + (b*b) has too many parentheses", on the other hand, is a purely > subjective opinion. Even if it is true that this is "commonly agreed > to" (and AFAIK you have no basis for that claim), that would still be a > subjective opinion - no matter how common that opinion is. > > Does that clear up your misunderstanding about "objective" and > "subjective" ? [...] > > Sometimes you might voice an opinion that is so extreme or uncommon that > people might tell you you are wrong, when saying they disagree would be > more appropriate - discussions here are not formal. Right. - And thus I've considered Bart's informal "too many parentheses" as just a sloppy formulation of "more than necessary" or "some spurious" parentheses. - We should grant him at least the same inaccuracies in his heated posts as he receives in any heated replies. Of course in the sense of clearness of communication it's not wrong to point out inaccurate statements. - Especially if such inaccuracies are deliberately used to rhetorically obfuscate previous wrong statements! Janis > [...]
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-06-04 06:38 -0700 |
| Message-ID | <86wlwebf3o.fsf@linuxsc.com> |
| In reply to | #399678 |
Bart <bc@freeuk.com> writes: > [...] Thank you for your response. I'm sorry my comments weren't more helpful to you.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-06-01 09:52 +0200 |
| Message-ID | <10vjdn8$22tgu$1@dont-email.me> |
| In reply to | #399561 |
On 31/05/2026 19:11, Bart wrote: > On 31/05/2026 17:04, Tim Rentsch wrote: >> Richard Harnden <richard.nospam@gmail.invalid> writes: >> >>> just write complex expressions in a way that a human can most >>> easily understand, >> >> Unfortunately, (1) different people have different ideas of what >> writing is most easily understood, and (2) different readers have >> different notions of which writings are easily understood, and >> which writings are not so easily understood. To make things >> worse "easily understood" is not a boolean condition, nor is it >> necessarily well-ordered -- "most easily understood" isn't always >> a well-defined quality, even for a given audience. >> >> Sadly the idea of writing in a way that is "most easily understood" >> has resulted in a race to the bottom, where writers are more and >> more encouraged to take the view that (some) readers are pretty >> much arbitrarily stupid, with the result that expressions become >> littered with scads of unnecessary parentheses that actually >> detract from ease of reading. Good writing is always a balance >> between too much and too little. > > Actual examples of too many parentheses? Any source code written in LISP :-) (And for too few parentheses, any source code in Forth.) From a quick grep of an SDK in a project I am working on, I saw this example : if ((((pData1 == NULL) || (pData2 == NULL))) || (Length == 0U)) The number of parentheses there is so high it's hard to see that not only is there an unnecessary extra parentheses for the first || operator, but there is a second set of extra parentheses around it. Eliminating these would give : if ((pData1 == NULL) || (pData2 == NULL) || (Length == 0U)) or, with an extra space for clarity, if ( (pData1 == NULL) || (pData2 == NULL) || (Length == 0U) ) That still leaves extra parentheses around the equality operators, but the decision to keep or remove them is subjective (as is the choice of "pData1 == NULL" vs. "!pData1"). But IMHO, the original line had at least two sets of completely redundant and unhelpful parentheses which made it harder to read - the reader is left wondering whether these parentheses are there for a purpose and have an effect on what should have been a simple and clear expression. The SDK also contains examples of parentheses used because it mixes relatively rare operators (shifts and binary operators). Parentheses around such sub-expressions are not uncommon, and can definitely be helpful, but the quantity here makes things hard to read. Ironically, though it is a macro, there are not "safety" parentheses around the argument in the expression. And yes, these really are the names of the macro in this code. #define CONVERTARGB88882ARGB4444(Color) \ ((((Color & 0xFFU) >> 4) & 0xFU) |\ (((((Color & 0xFF00U) >> 8) >> 4) & 0xFU) << 4) |\ (((((Color & 0xFF0000U) >> 16) >> 4) & 0xFU) << 8) | \ (((((Color & 0xFF000000U) >> 24) >> 4) & 0xFU) << 12)) #define CONVERTRGB5652ARGB8888(Color) \ (((((((Color >> 11) & 0x1FU) * 527) + 23) >> 6) << 16) |\ ((((((Color >> 5) & 0x3FU) * 259) + 33) >> 6) << 8) |\ ((((Color & 0x1FU) * 527) + 23) >> 6) | 0xFF000000) It can be argued that the parentheses themselves are not the problem here - it is doing too much in one expression. Static inline functions would make things clearer, as would a separation of the steps of breaking down the original colour format into parts, scaling or conversions, then building up the new colour format. Different named types for the different formats would go a long way towards usability and safety - at least using typedefs, but preferably using structs to make real different types. And surely nicer names could have been found!
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-06-01 02:42 -0700 |
| Message-ID | <10vjk5s$24d8c$2@kst.eternal-september.org> |
| In reply to | #399582 |
David Brown <david.brown@hesbynett.no> writes:
> On 31/05/2026 19:11, Bart wrote:
[...]
>> Actual examples of too many parentheses?
>
> Any source code written in LISP :-)
>
> (And for too few parentheses, any source code in Forth.)
>
>
> From a quick grep of an SDK in a project I am working on, I saw this
> example :
>
> if ((((pData1 == NULL) || (pData2 == NULL))) || (Length == 0U))
>
> The number of parentheses there is so high it's hard to see that not
> only is there an unnecessary extra parentheses for the first ||
> operator, but there is a second set of extra parentheses around
> it. Eliminating these would give :
>
> if ((pData1 == NULL) || (pData2 == NULL) || (Length == 0U))
>
> or, with an extra space for clarity,
>
> if ( (pData1 == NULL) || (pData2 == NULL) || (Length == 0U) )
>
> That still leaves extra parentheses around the equality operators, but
> the decision to keep or remove them is subjective (as is the choice of
> "pData1 == NULL" vs. "!pData1").
Yeah, I'd write that as
if (pData1 == NULL || pData2 == NULL || Length == 0U)
The fact that || binds more loosely than == is one of those things
that I arbitrarily find sufficiently intuitive.
[...]
> And yes, these really are the names of the macro in this code.
>
>
> #define CONVERTARGB88882ARGB4444(Color) \
> ((((Color & 0xFFU) >> 4) & 0xFU) |\
> (((((Color & 0xFF00U) >> 8) >> 4) & 0xFU) << 4) |\
> (((((Color & 0xFF0000U) >> 16) >> 4) & 0xFU) << 8) | \
> (((((Color & 0xFF000000U) >> 24) >> 4) & 0xFU) << 12))
>
> #define CONVERTRGB5652ARGB8888(Color) \
> (((((((Color >> 11) & 0x1FU) * 527) + 23) >> 6) << 16) |\
> ((((((Color >> 5) & 0x3FU) * 259) + 33) >> 6) << 8) |\
> ((((Color & 0x1FU) * 527) + 23) >> 6) | 0xFF000000)
In a macro definition, I'd parenthesize each occurrence of Color,
in case the argument is a more complicated expression, as well as
parenthesizing the entire definition (the latter was done here).
The rest of the parentheses feel excessive, but I frankly can't be
bothered to figure out which can be omitted without hurting clarity.
[...]
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-06-01 12:50 +0200 |
| Message-ID | <10vjo5q$259m3$1@dont-email.me> |
| In reply to | #399584 |
On 01/06/2026 11:42, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: >> On 31/05/2026 19:11, Bart wrote: > [...] >>> Actual examples of too many parentheses? >> >> Any source code written in LISP :-) >> >> (And for too few parentheses, any source code in Forth.) >> >> >> From a quick grep of an SDK in a project I am working on, I saw this >> example : >> >> if ((((pData1 == NULL) || (pData2 == NULL))) || (Length == 0U)) >> >> The number of parentheses there is so high it's hard to see that not >> only is there an unnecessary extra parentheses for the first || >> operator, but there is a second set of extra parentheses around >> it. Eliminating these would give : >> >> if ((pData1 == NULL) || (pData2 == NULL) || (Length == 0U)) >> >> or, with an extra space for clarity, >> >> if ( (pData1 == NULL) || (pData2 == NULL) || (Length == 0U) ) >> >> That still leaves extra parentheses around the equality operators, but >> the decision to keep or remove them is subjective (as is the choice of >> "pData1 == NULL" vs. "!pData1"). > > Yeah, I'd write that as > > if (pData1 == NULL || pData2 == NULL || Length == 0U) > > The fact that || binds more loosely than == is one of those things > that I arbitrarily find sufficiently intuitive. > Yes, the precedence levels of "==" and "||" (and "&&") are clearly intentional, and I think a lot of C programmers are happy with skipping the parentheses here. But some people would prefer to have the sub-expressions parenthesised, and I think that is fair enough too - it's not going to cause anyone extra difficulties in reading the line. > [...] > >> And yes, these really are the names of the macro in this code. >> >> >> #define CONVERTARGB88882ARGB4444(Color) \ >> ((((Color & 0xFFU) >> 4) & 0xFU) |\ >> (((((Color & 0xFF00U) >> 8) >> 4) & 0xFU) << 4) |\ >> (((((Color & 0xFF0000U) >> 16) >> 4) & 0xFU) << 8) | \ >> (((((Color & 0xFF000000U) >> 24) >> 4) & 0xFU) << 12)) >> >> #define CONVERTRGB5652ARGB8888(Color) \ >> (((((((Color >> 11) & 0x1FU) * 527) + 23) >> 6) << 16) |\ >> ((((((Color >> 5) & 0x3FU) * 259) + 33) >> 6) << 8) |\ >> ((((Color & 0x1FU) * 527) + 23) >> 6) | 0xFF000000) > > In a macro definition, I'd parenthesize each occurrence of Color, > in case the argument is a more complicated expression, as well as > parenthesizing the entire definition (the latter was done here). > The rest of the parentheses feel excessive, but I frankly can't be > bothered to figure out which can be omitted without hurting clarity. > That's the problem with code like that. People will think "that's a mess - I'll just assume / hope that it is correct". It is very difficult to check in code reviews, or to maintain, modify or adapt, so no one will bother figuring it out. It is "write-only" code. But while I know there are certainly some of the parentheses that could be removed, I am not sure that would actually improve the readability significantly. Like many people, I prefer not to rely on knowledge of the relative precedences of shifts and bitwise operators. My preference would be for major refactoring, not for removing (or adding) parentheses.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-06-01 11:47 +0100 |
| Message-ID | <10vjnv7$25mnf$1@dont-email.me> |
| In reply to | #399582 |
On 01/06/2026 08:52, David Brown wrote:
> On 31/05/2026 19:11, Bart wrote:
>> On 31/05/2026 17:04, Tim Rentsch wrote:
>>> Richard Harnden <richard.nospam@gmail.invalid> writes:
>>>
>>>> just write complex expressions in a way that a human can most
>>>> easily understand,
>>>
>>> Unfortunately, (1) different people have different ideas of what
>>> writing is most easily understood, and (2) different readers have
>>> different notions of which writings are easily understood, and
>>> which writings are not so easily understood. To make things
>>> worse "easily understood" is not a boolean condition, nor is it
>>> necessarily well-ordered -- "most easily understood" isn't always
>>> a well-defined quality, even for a given audience.
>>>
>>> Sadly the idea of writing in a way that is "most easily understood"
>>> has resulted in a race to the bottom, where writers are more and
>>> more encouraged to take the view that (some) readers are pretty
>>> much arbitrarily stupid, with the result that expressions become
>>> littered with scads of unnecessary parentheses that actually
>>> detract from ease of reading. Good writing is always a balance
>>> between too much and too little.
>>
>> Actual examples of too many parentheses?
>
> Any source code written in LISP :-)
>
> (And for too few parentheses, any source code in Forth.)
>
>
> From a quick grep of an SDK in a project I am working on, I saw this
> example :
>
> if ((((pData1 == NULL) || (pData2 == NULL))) || (Length == 0U))
>
> The number of parentheses there is so high it's hard to see that not
> only is there an unnecessary extra parentheses for the first ||
> operator, but there is a second set of extra parentheses around it.
> Eliminating these would give :
>
> if ((pData1 == NULL) || (pData2 == NULL) || (Length == 0U))
>
> or, with an extra space for clarity,
>
> if ( (pData1 == NULL) || (pData2 == NULL) || (Length == 0U) )
>
> That still leaves extra parentheses around the equality operators, but
> the decision to keep or remove them is subjective (as is the choice of
> "pData1 == NULL" vs. "!pData1").
Maybe it's due to || being a symbol; compare:
if (pData1 == NULL || pData2 == NULL || Length == 0U)
if (pData1 == NULL or pData2 == NULL or Length == 0U)
To me, || seems to draw in the terms on either side as strongly as ==.
That happens less using 'or'.
(Both are valid C if using iso646.h.)
> But IMHO, the original line had at least two sets of completely
> redundant and unhelpful parentheses which made it harder to read - the
> reader is left wondering whether these parentheses are there for a
> purpose and have an effect on what should have been a simple and clear
> expression.
The pattern seems to be '((a || b)) || c) || d' so maybe the author
didn't understand that || is parsed LTR anyway.
>
> The SDK also contains examples of parentheses used because it mixes
> relatively rare operators (shifts and binary operators). Parentheses
> around such sub-expressions are not uncommon, and can definitely be
> helpful, but the quantity here makes things hard to read. Ironically,
> though it is a macro, there are not "safety" parentheses around the
> argument in the expression.
>
> And yes, these really are the names of the macro in this code.
>
>
> #define CONVERTARGB88882ARGB4444(Color) \
> ((((Color & 0xFFU) >> 4) & 0xFU) |\
> (((((Color & 0xFF00U) >> 8) >> 4) & 0xFU) << 4) |\
> (((((Color & 0xFF0000U) >> 16) >> 4) & 0xFU) << 8) | \
> (((((Color & 0xFF000000U) >> 24) >> 4) & 0xFU) << 12))
> #define CONVERTRGB5652ARGB8888(Color) \
> (((((((Color >> 11) & 0x1FU) * 527) + 23) >> 6) << 16) |\
> ((((((Color >> 5) & 0x3FU) * 259) + 33) >> 6) << 8) |\
> ((((Color & 0x1FU) * 527) + 23) >> 6) | 0xFF000000)
>
> It can be argued that the parentheses themselves are not the problem
> here - it is doing too much in one expression. Static inline functions
> would make things clearer, as would a separation of the steps of
> breaking down the original colour format into parts, scaling or
> conversions, then building up the new colour format. Different named
> types for the different formats would go a long way towards usability
> and safety - at least using typedefs, but preferably using structs to
> make real different types. And surely nicer names could have been found!
>
Your examples actually look reasonable. In fact, it could probably do
with more parentheses around 'Color'... (I've just seen you've already
mentioned this!)
The first part of the second has to apply 6 operations to 'Color' in
strict LTR order. Using parentheses ensures not having to worry about
precedence, since the ops are '>> & * + >> <<'
The macro names seem self-explanatory too, although they could do with
some underscores.
But anything involving macros probably doesn't count; you expect () to
be heavily used in the expansion.
This is an example from Lua:
op_arith(L, l_addi, luai_numadd);
On the face of it, perfectly reasonable. But it expands to this:
{TValue*v1=(&((base+(((void)0),((((int)((((i)>>((((0+7)+8)+1)))&
((~((~(Instruction)0)<<(8)))<<(0))))))))))->val);TValue*v2=(&((
base+(((void)0),((((int)((((i)>>(((((0+7)+8)+1)+8)))&((~((~(
Instruction)0)<<(8)))<<(0))))))))))->val);{StkId ra=(base+(((int)
((((i)>>((0+7)))&((~((~(Instruction)0)<<(8)))<<(0)))))));if(((((v1)
)->tt_)==(((3)|((0)<<4))))&&((((v2))->tt_)==(((3)|((0)<<4))))){
lua_Integer i1=(((void)0),(((v1)->value_).i));lua_Integer i2=(((void)
0),(((v2)->value_).i));pc++;{TValue*io=((&(ra)->val));((io)->value_)
.i=(((lua_Integer)(((lua_Unsigned)(i1))+((lua_Unsigned)(i2)))));((io)
->tt_=(((3)|((0)<<4))));};}else{lua_Number n1;lua_Number n2;if((((((v1))
->tt_)==(((3)|((1)<<4))))?((n1)=(((void)0),(((v1)->value_).n)),1):(((((
v1))->tt_)==(((3)|((0)<<4))))?((n1)=((lua_Number)(((((void)0),(((v1)->
value_).i))))),1):0))&&(((((v2))->tt_)==(((3)|((1)<<4))))?((n2)=(((void)
0),(((v2)->value_).n)),1):(((((v2))->tt_)==(((3)|((0)<<4))))?((n2)=((
lua_Number)(((((void)0),(((v2)->value_).i))))),1):0))){pc++;{TValue*
io=((&(ra)->val));((io)->value_).n=(((n1)+(n2)));((io)->tt_=(((3)|
((1)<<4))));};}};};};
(I had fun debugging this at one time in my compiler. I've no idea how
the original developer did so.)
Not too many () in the macro definitions, but I can only see the top
level; here deeply nested macros are used.
[toc] | [prev] | [next] | [standalone]
Page 10 of 13 — ← Prev page 1 … 8 9 [10] 11 12 13 Next page →
Back to top | Article view | comp.lang.c
csiph-web