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 268 — 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 scott@slp53.sl.home (Scott Lurndal) - 2026-06-06 15:13 +0000
Re: this girl calls c ugly scott@slp53.sl.home (Scott Lurndal) - 2026-06-06 17:53 +0000
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-04 11:59 -0700
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-04 15:21 +0200
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-04 06:38 -0700
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-01 09:52 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-01 02:42 -0700
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-01 12:50 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-01 11:47 +0100
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-01 12:55 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-01 14:39 -0700
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-01 15:11 -0700
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-02 08:41 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-02 02:07 -0700
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-02 11:38 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-02 05:01 -0700
It is not futile to change the subject line (Was: this girl calls c ugly) gazelle@shell.xmission.com (Kenny McCormack) - 2026-06-02 12:39 +0000
Re: It is not futile to change the subject line (Was: this girl calls c ugly) gazelle@shell.xmission.com (Kenny McCormack) - 2026-06-02 12:42 +0000
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-02 11:46 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-02 11:09 +0100
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-02 05:25 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-02 14:20 +0100
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-02 15:12 -0700
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-02 04:16 -0700
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-01 15:23 -0700
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-01 16:06 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-01 23:24 +0100
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-02 11:35 +0200
Operator precedence in other (non-C, but "C-like") languages (Was: something about a girl) gazelle@shell.xmission.com (Kenny McCormack) - 2026-06-02 12:36 +0000
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-01 11:04 +0000
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-01 14:04 +0200
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-01 18:48 +0000
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-01 21:04 +0100
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-02 09:17 +0200
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-02 09:09 +0200
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-02 12:07 +0000
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-02 14:37 +0200
Microcontroller software stacks (was Re: this girl calls c ugly) scott@slp53.sl.home (Scott Lurndal) - 2026-06-02 15:06 +0000
Re: 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 11 of 14 — ← Prev page 1 … 9 10 [11] 12 13 14 Next page →
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-06-05 03:02 +0000 |
| Message-ID | <10vte7f$id4$4@reader1.panix.com> |
| In reply to | #399728 |
In article <1BoUR.3$lmCb.1@fx22.iad>, Scott Lurndal <slp53@pacbell.net> wrote:
>cross@spitfire.i.gajendra.net (Dan Cross) writes:
>>[snip]
>>>getch()
>>>{
>>> register int c, lastst;
>>>
>>> while ((c=getc1())=='/' && !instring)
>>> {
>>> if ((c=getc1())!='*')
>>> {
>>> pushback(c);
>>> return('/');
>>> }
>>> if (!skipcom)
>>> {putc('/',fout); putc('*', fout);}
>>> lastst=0;
>>> while ( (c = getc1()) != '\0')
>>> {
>>> if (lastst && c=='/')
>>> {
>>> if (!skipcom)
>>> putc('/', fout);
>>> break;
>>> }
>>> if (c=='\n' || !skipcom)
>>> putc(c, fout);
>>> lastst = (c=='*');
>>> }
>>> if (c=='\0')break;
>>> }
>>> return(c);
>>>}
>>
>>Yeah, that's from `cc.c`, right?
>
>No, it's from cpp.c
>
>$ ls /work/reference/collegetapes/sltape/v6cc/
>c0.c c00.c c01.c c02.c c03.c c04.c c05.c c1.h
>c10.c c11.c c12.c c13.c c2.h c20.c c21.c cc.c cpp.c
Oh interesting. I don't have a `cpp.c` in my v6 archive.
I wonder what else I'm missing.
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-06-05 14:04 +0000 |
| Message-ID | <DHAUR.47540$0o1c.29921@fx08.iad> |
| In reply to | #399736 |
cross@spitfire.i.gajendra.net (Dan Cross) writes:
>In article <1BoUR.3$lmCb.1@fx22.iad>, Scott Lurndal <slp53@pacbell.net> wrote:
>>cross@spitfire.i.gajendra.net (Dan Cross) writes:
>>>[snip]
<snip>
>>>Yeah, that's from `cc.c`, right?
>>
>>No, it's from cpp.c
>>
>>$ ls /work/reference/collegetapes/sltape/v6cc/
>>c0.c c00.c c01.c c02.c c03.c c04.c c05.c c1.h
>>c10.c c11.c c12.c c13.c c2.h c20.c c21.c cc.c cpp.c
>
>Oh interesting. I don't have a `cpp.c` in my v6 archive.
>
>I wonder what else I'm missing.
For your archive, cpp.c
#
# include <stdio.h>
/* C command */
# define SBSIZE 15000
# define SYMSIZ 1500
# define TOKLEN 16
# define DROP (-2)
# define SAME 0
# define MAXINC 10
char sbf[SBSIZE];
# define CHSPACE 1000
char ts[CHSPACE+50];
# define EXPSIZE 500
char *strdex(), *copy(), *calloc(), *token(), *coptok();
char *tsa ts;
char *tsp ts;
char *fnames[MAXINC];
# define LINELEN 512
FILE *fin;
FILE *fout;
int instring;
char direct[50];
int nd 1;
char *dirs[10] {direct, 0};
char nfil[100];
int pflag;
int depth;
int skipcom;
FILE *fins[MAXINC];
int ifno;
char *lp;
char *line;
# define NPREDEF 20
char *prespc[NPREDEF];
char **predef prespc;
char *punspc[NPREDEF];
char **prund punspc;
char **predp;
int lineno[MAXINC];
int exfail;
struct symtab {
char name[TOKLEN];
char *value;
} *symtab, *lookup();
struct symtab *defloc;
struct symtab *udfloc;
struct symtab *incloc;
struct symtab *ifloc;
struct symtab *elsloc;
struct symtab *eifloc;
struct symtab *ifdloc;
struct symtab *ifnloc;
struct symtab *sysloc;
struct symtab *lneloc;
struct symtab *prdloc;
int trulvl;
int flslvl;
char *stringbuf;
mainpp(argc,argv)
char *argv[];
{
int i;
# ifdef tgp
int ifbrk;
# endif
char ln[LINELEN];
register int c;
register char *rlp;
char *sp;
struct symtab stab[SYMSIZ];
fin = stdin;
fout = stdout;
# ifdef unix
fnames[ifno=0] = "";
# endif
# ifdef gcos
fnames[ifno=0] = "s*";
# endif
# ifdef ibm
fnames[ifno=0] = "";
# endif
for(i=1; i<argc; i++)
{
switch(argv[i][0])
{
case '-':
switch(argv[i][1])
{
case 'P':
pflag++;
case 'E':
continue;
case 'D':
if (predef>prespc+NPREDEF)
{
error("too many -D options, ignoring %s",argv[i]);
continue;
}
*predef++ = argv[i]+2;
continue;
case 'U':
if (prund>punspc+NPREDEF)
{
error("too many -U options, ignoring %s",argv[i]);
continue;
}
*prund++ = argv[i]+2;
continue;
case 'I':
if (nd>8)
error("excessive -I file (%s) ignored",argv[i]);
else
dirs[nd++] = argv[i]+2;
continue;
case '\0': continue;
default:
error("unknown flag %s", argv[i]);
continue;
}
default:
if (fin==stdin)
{
fin = fopen(argv[i], "r");
if (fin==NULL)
{
error("No source file %s",argv[i]);
exit(8);
}
fnames[ifno]=argv[i];
strcpy(direct, argv[i]);
for(sp=direct; *sp; sp++);
while (sp>direct && *sp != '/') sp--;
# ifdef unix
if (sp==direct)
*sp++ = '.';
# endif
*sp=0; /* direct now has place where source file is */
}
else
if (fout==stdout)
{
fout= fopen(argv[i], "w");
if (fout==NULL)
{
error("Can't write %s", argv[i]);
exit(8);
}
}
else
error("extraneous name %s", argv[i]);
}
}
fins[ifno]=fin;
exfail = 0;
/* after user -I files here are the standard include libraries */
# ifdef unix
dirs[nd++] = "/usr/include";
# endif
# ifdef gcos
dirs[nd++] = "cc";
# endif
# ifdef ibm
dirs[nd++] = "stdio.";
# endif
/* dirs[nd++] = "/compool"; */
dirs[nd++] = 0;
symtab = stab;
for (c=0; c<SYMSIZ; c++) {
stab[c].name[0] = '\0';
stab[c].value = 0;
}
insym(&defloc, "define");
insym(&udfloc, "undef");
insym(&incloc, "include");
insym(&elsloc, "else");
insym(&eifloc, "endif");
insym(&ifdloc, "ifdef");
insym(&ifnloc, "ifndef");
insym(&ifloc, "if");
# ifdef unix
insym(&sysloc, "unix");
# endif
# ifdef gcos
insym (&sysloc, "gcos");
# endif
# ifdef ibm
insym (&sysloc, "ibm");
# endif
insym(&lneloc, "line");
predp=predef;
while (predp>prespc)
if (sp=strdex(*--predp, '='))
{
*sp++=0;
stsym(*predp, sp);
}
else
insym(&prdloc, *predp);
predp=prund;
while (predp>punspc)
{
if (sp=strdex(*--predp, '='))
*sp++=0;
lookup(*predp, DROP);
}
stringbuf = sbf;
trulvl = 0;
flslvl = 0;
line = ln;
lineno[0] = 1;
if (pflag==0) fprintf(fout, "# 1 \"%s\"\n", fnames[ifno]);
while(getline()) {
skipcom=0;
if (ln[0] != '#' && flslvl==0)
{
# ifdef tgp
ifbrk= checklen(line);
# endif
for (rlp = line; c = *rlp++;)
putc(c, fout);
# ifdef tgp
if (ifbrk)
fprintf(fout,"\n# %d",lineno[ifno]);
# endif
}
putc('\n', fout);
}
# ifdef tgp
checklen(line);
# endif
for(rlp=line; c = *rlp++;)
putc(c,fout);
}
getline()
{
register int c, sc, state;
struct symtab *np;
char *namep, *filname, **dirp;
int filok, inctype;
lp = line;
*lp = '\0';
state = 0;
if ((c=getch()) == '#')
state = 1;
while (c!='\n' && c!='\0') {
if (letter(c)) {
namep = lp;
sch(c);
while (letnum(c=getch()))
sch(c);
sch('\0');
lp--;
if (state==6)
{
lookup(namep, DROP);
goto out;
}
if (state>3 && state <6) {
if (flslvl==0 &&(state+!lookup(namep,-1)->name[0])==5)
trulvl++;
else
flslvl++;
out:
while (c!='\n' && c!= '\0')
c = getch();
return(c);
}
if (state==3) /* include */
if (*namep != '"' && *namep != '<')
{
error("Bad include syntax", 0);
state=1;
}
if (state!=2 || flslvl==0)
{
pushback(c);
np = lookup(namep, state);
c = getch();
}
if (state==1) {
if (np==defloc)
skipcom = state = 2;
else if (np==incloc)
state = 3;
else if (np==ifnloc)
state = 4;
else if (np==ifdloc)
state = 5;
else if (np==eifloc) {
if (flslvl)
--flslvl;
else if (trulvl)
--trulvl;
else errback("If-less endif",0);
goto out;
}
else if (np==elsloc) {
if (flslvl)
--flslvl? ++flslvl : ++trulvl;
else if (trulvl)
{++flslvl; --trulvl;}
else
errback("If-less else",0);
goto out;
}
else if (np==udfloc) {
state=6;
}
else if (np==ifloc) {
/*
if (flslvl ==0 && yyparse())
*/ error("IF not implemented, true assumed",0); if (1)
trulvl++;
else
flslvl++;
return('\n');
}
else if (np==lneloc)
{
if(pflag==0) fprintf(fout, "# ");
lp=line;
for(; c !='\n' && c != '\0'; c=getch())
if (!pflag)
sch(c);
sch('\0');
return(c);
}
else {
errback("Undefined control",0);
while (c!='\n' && c!='\0')
c = getch();
return(c);
}
} else if (state==2) {
if (flslvl)
goto out;
np->value = stringbuf;
if (c != '\n' && c != 0)
{
savch(c);
while ((c=getch())!='\n' && c!='\0')
{
if (c== '\\')
{
c = getch();
if (c=='\n')continue;
savch('\\');
}
savch(c);
}
}
savch('\0');
return(1);
}
continue;
} else if ((sc=c) == '\'' || sc== '"' || (state==3 && sc== '<')) {
sch(sc);
filname = lp;
inctype = sc=='<';
if (sc== '<')
{
/*
fprintf(fout==stdout?stderr:stdout, "note: include <> obsolete, use \"\"\n");
*/
sc= '>';
}
instring++;
while ((c=getch())!=sc && c!='\n' && c!='\0') {
sch(c);
if (c=='\\')
sch(getch());
}
instring = 0;
if (flslvl)
goto out;
if (state==3) {
if (flslvl)
goto out;
*lp = '\0';
while ((c=getch())!='\n' && c!='\0');
if (ifno+1 >=MAXINC)
error("Unreasonable include nesting",0);
filok=0;
for(dirp=dirs+inctype; *dirp; dirp++)
{
if (filname[0]=='/' || **dirp=='\0')
strcpy(nfil,filname);
else
{
strcpy(nfil,*dirp);
# ifdef unix
strcat(nfil, "/");
# endif
# ifdef gcos
strcat(nfil, "/");
# endif
# ifdef ibm
strcat(nfil, ".");
# endif
strcat(nfil, filname);
}
if ( (fins[ifno+1]=fopen(nfil, "r"))!=NULL)
{
filok=1;
fin = fins[++ifno];
break;
}
}
if (filok==0)
errback("Can't find include file %s", filname);
else
{
if (pflag==0) fprintf(fout, "\n# 1 \"%s\"", filname);
lineno[ifno]=1;
fnames[ifno] = copy(filname);
}
return(c);
}
}
sch(sc=c);
c = getch();
if (isdigit(sc))
{
for (;isalpha(c) || isdigit(c); c=getch())
sch(c);
}
}
sch('\0');
if (state>1)
errback("Control syntax",0);
return(c);
}
insym(sp, namep)
struct symtab **sp;
char *namep;
{
register struct symtab *np;
*sp = np = lookup(namep, 1);
np -> value = np -> name;
}
stsym(namep, valp)
char *namep, *valp;
{
register struct symtab *np;
np = lookup(namep, 1);
np->value = valp;
}
error(s, x)
char *s;
{
FILE *efout;
efout = fout==stdout ? stderr : stdout;
if (fnames[ifno][0])
fprintf(efout,"%s: %d: ", fnames[ifno], lineno[ifno]);
fprintf(efout, s, x);
putc('\n',efout);
exfail++;
}
errback(s,x)
char *s;
{
lineno[ifno]--;
error(s,x);
lineno[ifno]++;
}
sch(c)
{
register char *rlp;
rlp = lp;
if (rlp==line+LINELEN-2)
error("Line overflow", 0);
*rlp++ = c;
if (rlp>line+LINELEN-1)
rlp = line+LINELEN-1;
lp = rlp;
}
savch(c)
{
*stringbuf++ = c;
if (stringbuf-sbf < SBSIZE)
return;
error("Too much defining", 0);
exit(exfail);
}
getch()
{
register int c, lastst;
while ((c=getc1())=='/' && !instring)
{
if ((c=getc1())!='*')
{
pushback(c);
return('/');
}
if (!skipcom)
{putc('/',fout); putc('*', fout);}
lastst=0;
while ( (c = getc1()) != '\0')
{
if (lastst && c=='/')
{
if (!skipcom)
putc('/', fout);
break;
}
if (c=='\n' || !skipcom)
putc(c, fout);
lastst = (c=='*');
}
if (c=='\0')break;
}
return(c);
}
char pushbuff[EXPSIZE];
char *pushp pushbuff;
pushback(c)
{
*++pushp = c;
if (pushp>pushbuff+EXPSIZE) {
error("too much backup", 0);
exit(8);
}
}
getc1()
{
register c;
if (*pushp !=0)
return(*pushp--);
depth=0;
if ((c = getc(fin)) == EOF && ifno>0) {
fclose(fin);
fin = fins[--ifno];
if (pflag==0) fprintf(fout, "\n# %d \"%s\"\n",lineno[ifno], fnames[ifno]);
c = getc1();
if (c=='\n') lineno[ifno]--;
}
if (c==EOF)
return(0);
if (c=='\n' )
lineno[ifno]++;
return(c);
}
struct symtab *
lookup(namep, enterf)
char *namep;
{
register char *np, *snp;
register struct symtab *sp;
int i, c, around;
np = namep;
snp = np+TOKLEN;
around = i = 0;
while ( (c = *np++ ) && (np-snp)<0)
{
i =+ c;
}
i =% SYMSIZ;
sp = &symtab[i];
while (sp->name[0]) {
if (sp->name[0] != DROP)
{
snp = sp->name;
np = namep;
while (*snp++ == *np)
if (*np++ == '\0' || np==namep+TOKLEN) {
if (enterf==DROP)
{
sp->name[0]= DROP;
return(sp);
}
if (!enterf)
subst(namep, sp);
return(sp);
}
}
if (++sp >= &symtab[SYMSIZ])
if (around++)
{
error("too many defines", 0);
exit(exfail);
}
else
sp = symtab;
}
if (enterf>0) {
snp = namep;
for (np = &sp->name[0]; np < &sp->name[TOKLEN];)
if (*np++ = *snp)
snp++;
}
return(sp);
}
char revbuff[200], *bp;
backsch(c)
{
if (bp-revbuff > 200)
error("Excessive define looping", bp--);
*bp++ = c;
}
subst(np, sp)
char *np;
struct symtab *sp;
{
register char *vp;
int macflg;
lp = np;
bp = revbuff;
if (depth++>100)
{
error("define recursion loop on %s", np);
return;
}
if ((vp = sp->value) == 0)
return;
macflg= (*vp == '(');
/* arrange that define unix unix still
has no effect, avoiding rescanning */
while (blank(*vp))
vp++;
if (strcmp(sp->name,vp) == SAME)
{
while (*vp)
sch(*vp++);
return;
}
if (macflg)
expdef(vp);
else
while (*vp)
backsch(*vp++);
while (bp>revbuff)
pushback(*--bp);
}
char *
copy(as)
char as[];
{
register char *otsp, *s;
int i;
otsp = tsp;
s = as;
while(*tsp++ = *s++);
if (tsp >tsa+CHSPACE)
{
# ifdef unix
tsp = tsa = i = calloc(CHSPACE+50,sizeof(char));
if (i== NULL)
# endif
{
error("no space for file names", 0);
exit(8);
}
}
return(otsp);
}
expdef(proto)
char *proto;
{
char buffer[EXPSIZE], *parg[20], *pval[20], name[20], *cspace, *wp;
char protcop[EXPSIZE], *pr;
int narg, k, c;
pr = protcop;
while (*pr++ = *proto++)
if (pr>=protcop+EXPSIZE){
error("define prototype too big", 0);
exit(8);
}
proto= protcop;
for (narg=0; (parg[narg] = token(&proto)) != 0; narg++)
;
/* now scan input */
cspace = buffer;
while ((c=getch()) == ' ');
if (c != '(')
{
error("defined function requires arguments", 0);
return;
}
pushback(c);
for(k=0; pval[k] = coptok(&cspace, buffer+EXPSIZE); k++);
if (k!=narg)
{
error("define argument mismatch");
return;
}
while (c= *proto++)
{
if (!letter(c))
backsch(c);
else
{
wp = name;
*wp++ = c;
while (letnum(*proto))
*wp++ = *proto++;
*wp = 0;
for (k=0; k<narg; k++)
if(strcmp(name,parg[k]) == SAME)
break;
wp = k <narg ? pval[k] : name;
while (*wp) backsch(*wp++);
}
}
}
char *
token(cpp) char **cpp;
{
char *val;
int stc;
stc = **cpp;
*(*cpp)++ = '\0';
if (stc==')') return(0);
while (**cpp == ' ') (*cpp)++;
for (val = *cpp; (stc= **cpp) != ',' && stc!= ')'; (*cpp)++)
{
if (!letnum(stc) || (val == *cpp && !letter(stc)))
{
error("define prototype argument error");
return(0);
}
}
return(val);
}
char *
coptok (cpp, clim) char **cpp, *clim;
{
char *val;
int stc, stop,paren;
paren = stop = 0;
val = *cpp;
if (getch() == ')')
return(0);
while (((stc = getch()) != ',' && stc != ')' ) || paren > 0 || stop >0)
{
if (stc == '\0')
{
error("non terminated macro call", 0);
val = 0;
break;
}
if (stop == 0 && (stc == '"' || stc == '\''))
stop = stc;
else if (stc==stop)
stop=0;
if ( stc == '\\')
{
stc = getch();
if (stop>0 || (stc != ',' && stc != '\\'))
*(*cpp)++ = '\\';
*(*cpp)++ = stc;
}
else
{
*(*cpp)++ = stc;
if (stop==0)
{
if (stc == '(')
paren++;
if (stc == ')')
paren--;
}
}
if (*cpp >= clim)
{
error("define argument too long",0);
exit(8);
}
}
*(*cpp)++ = 0;
pushback(stc);
return(val);
}
letter(c)
{
if (isalpha(c) || c == '_')
return (1);
else
return(0);
}
letnum(c)
{
if (letter(c) || isdigit(c))
return(1);
else
return(0);
}
blank(c)
{
return(c==' ' || c== '\t');
}
char *
strdex(s,c)
char *s;
{
while (*s)
if (*s==c)
return(s);
else
s++;
return(0);
}
# ifdef tgp
# define MAXOUT 80
checklen(sln)
char *sln;
{
/* for tgp: scans string sln, and puts in newlines for blanks,
where it likes, but to make lines less than MAXOUT chars long */
char *p, *s, *st;
int stopc, back, ifdone, c;
st=s=sln;
ifdone=p=stopc=back=0;
while (c= *s++)
{
if (c == '\\')
back=2;
if (back==0)
{
if (stopc== c)
stopc=0;
else
if (c == '"' || c == '\'')
stopc= c;
}
if (back>0)back--;
if (s-st >MAXOUT && p != 0)
{
st=p;
*p= '\n';
ifdone=1;
}
if (stopc==0 && back==0)
if (c==' ') p=s-1;;
}
return(ifdone);
}
# endif
main(argc,argv) char *argv[]; {
exit(mainpp (argc,argv) );
}
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-06-06 03:49 +0000 |
| Message-ID | <11005ca$gc8$3@reader1.panix.com> |
| In reply to | #399750 |
In article <DHAUR.47540$0o1c.29921@fx08.iad>, Scott Lurndal <slp53@pacbell.net> wrote: >cross@spitfire.i.gajendra.net (Dan Cross) writes: >>In article <1BoUR.3$lmCb.1@fx22.iad>, Scott Lurndal <slp53@pacbell.net> wrote: >>>cross@spitfire.i.gajendra.net (Dan Cross) writes: >>>>[snip] > <snip> >>>>Yeah, that's from `cc.c`, right? >>> >>>No, it's from cpp.c >>> >>>$ ls /work/reference/collegetapes/sltape/v6cc/ >>>c0.c c00.c c01.c c02.c c03.c c04.c c05.c c1.h >>>c10.c c11.c c12.c c13.c c2.h c20.c c21.c cc.c cpp.c >> >>Oh interesting. I don't have a `cpp.c` in my v6 archive. >> >>I wonder what else I'm missing. > > [snip] Thanks! This is an artifact definitely worth preserving. As far as I know, it's not in any of the extant V6 archives. I'll shoot you an email, if that's ok. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-06-06 15:13 +0000 |
| Message-ID | <uOWUR.178488$DvK9.138773@fx48.iad> |
| In reply to | #399764 |
cross@spitfire.i.gajendra.net (Dan Cross) writes: >In article <DHAUR.47540$0o1c.29921@fx08.iad>, >Scott Lurndal <slp53@pacbell.net> wrote: >>cross@spitfire.i.gajendra.net (Dan Cross) writes: >>>In article <1BoUR.3$lmCb.1@fx22.iad>, Scott Lurndal <slp53@pacbell.net> wrote: >>>>cross@spitfire.i.gajendra.net (Dan Cross) writes: >>>>>[snip] >> <snip> >>>>>Yeah, that's from `cc.c`, right? >>>> >>>>No, it's from cpp.c >>>> >>>>$ ls /work/reference/collegetapes/sltape/v6cc/ >>>>c0.c c00.c c01.c c02.c c03.c c04.c c05.c c1.h >>>>c10.c c11.c c12.c c13.c c2.h c20.c c21.c cc.c cpp.c >>> >>>Oh interesting. I don't have a `cpp.c` in my v6 archive. >>> >>>I wonder what else I'm missing. >> >> [snip] > >Thanks! This is an artifact definitely worth preserving. As >far as I know, it's not in any of the extant V6 archives. I'll >shoot you an email, if that's ok. > > - Dan C. >
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-06-06 17:53 +0000 |
| Message-ID | <18ZUR.498853$u0G1.241809@fx01.iad> |
| In reply to | #399764 |
cross@spitfire.i.gajendra.net (Dan Cross) writes: >In article <DHAUR.47540$0o1c.29921@fx08.iad>, >Scott Lurndal <slp53@pacbell.net> wrote: >>cross@spitfire.i.gajendra.net (Dan Cross) writes: >>>In article <1BoUR.3$lmCb.1@fx22.iad>, Scott Lurndal <slp53@pacbell.net> wrote: >>>>cross@spitfire.i.gajendra.net (Dan Cross) writes: >>>>>[snip] >> <snip> >>>>>Yeah, that's from `cc.c`, right? >>>> >>>>No, it's from cpp.c >>>> >>>>$ ls /work/reference/collegetapes/sltape/v6cc/ >>>>c0.c c00.c c01.c c02.c c03.c c04.c c05.c c1.h >>>>c10.c c11.c c12.c c13.c c2.h c20.c c21.c cc.c cpp.c >>> >>>Oh interesting. I don't have a `cpp.c` in my v6 archive. >>> >>>I wonder what else I'm missing. >> >> [snip] > >Thanks! This is an artifact definitely worth preserving. As >far as I know, it's not in any of the extant V6 archives. I'll >shoot you an email, if that's ok. A a version of cpp that was used with the portable C compiler (PCC) is here. It has a -C option to preserve comments in the processed output. https://github.com/IanHarvey/pcc/blob/master/cc/cpp/cpp.c
[toc] | [prev] | [next] | [standalone]
| 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]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-06-01 12:55 +0200 |
| Message-ID | <10vjofv$259m3$2@dont-email.me> |
| In reply to | #399587 |
On 01/06/2026 12:47, Bart wrote:
> 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.
Indeed.
>
> But anything involving macros probably doesn't count; you expect () to
> be heavily used in the expansion.
I think macro definitions "count", as do how the macros are used in
code. But the full expansions do not "count" as they are not something
normally read or written by the programmer. (I appreciate that you need
to see such things sometimes when implementing a compiler, and
occasionally people look at the output of a pre-processor, but in normal
use, the appearance of a macro expansion does not matter.)
>
> 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.)
I assume the author did so built it up in parts. The readability is in
the source - and the source is "op_arith(L, l_addi, luai_numadd);" -
there are not too many parentheses there.
>
> 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]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-06-01 14:39 -0700 |
| Message-ID | <10vku5o$2glfs$2@kst.eternal-september.org> |
| In reply to | #399587 |
Bart <bc@freeuk.com> writes:
> On 01/06/2026 08:52, David Brown wrote:
[...]
>> 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.)
The "and" macro in <iso646.h> is exactly equivalent to "||".
If your intuition tells you they have different precedences, that
could be a problem. On the other hand, if you choose to use them
differently in ways that don't break anything, that's fine.
Digression: Perl borrows most or all of C's operators, and keeps
the same precedences. "Operators borrowed from C keep the same
precedence relationship with each other, even where C's precedence
is slightly screwy." But Perl has "and" and "or" operators that
work like "&&" and "||" but have lower precedence (that turns out
to be convenient in some contexts).
I vaguely recall that there's some language that uses the ?: syntax
for the conditional operator, but with a different precedence and/or
associativity than C. I can't remember which language it is.
[...]
--
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 | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-06-01 15:11 -0700 |
| Message-ID | <10vl02a$2glfs$4@kst.eternal-september.org> |
| In reply to | #399595 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
[...]
> I vaguely recall that there's some language that uses the ?: syntax
> for the conditional operator, but with a different precedence and/or
> associativity than C. I can't remember which language it is.
The language I was thinking of is PHP. C's ?: operator associates
right-to-left, which makes it possible to write chained conditional
expressions like:
cond1 ? expr1 :
cond2 ? expr2 :
cond3 ? expr3 :
default_expr
PHP's ?: operator originally associated right-to-left.
Newer versions of PHP require parentheses.
--
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-02 08:41 +0200 |
| Message-ID | <10vltvd$2ne3j$1@dont-email.me> |
| In reply to | #399596 |
On 02/06/2026 00:11, Keith Thompson wrote: > Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > [...] >> I vaguely recall that there's some language that uses the ?: syntax >> for the conditional operator, but with a different precedence and/or >> associativity than C. I can't remember which language it is. > > The language I was thinking of is PHP. C's ?: operator associates > right-to-left, which makes it possible to write chained conditional > expressions like: > > cond1 ? expr1 : > cond2 ? expr2 : > cond3 ? expr3 : > default_expr > > PHP's ?: operator originally associated right-to-left. > Newer versions of PHP require parentheses. > I thought you were thinking of C++, where ? has the same precedence as assignment, while in C it has higher precedence. It does not make a lot of difference, and if you are writing an expression where it matters, then I think parentheses would be a good idea. <https://cppreference.com/c/language/operator_precedence> <https://cppreference.com/cpp/language/operator_precedence>
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-06-02 02:07 -0700 |
| Message-ID | <10vm6h4$2qdor$1@kst.eternal-september.org> |
| In reply to | #399601 |
David Brown <david.brown@hesbynett.no> writes:
> On 02/06/2026 00:11, Keith Thompson wrote:
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> [...]
>>> I vaguely recall that there's some language that uses the ?: syntax
>>> for the conditional operator, but with a different precedence and/or
>>> associativity than C. I can't remember which language it is.
>>
>> The language I was thinking of is PHP. C's ?: operator associates
>> right-to-left, which makes it possible to write chained conditional
>> expressions like:
>> cond1 ? expr1 :
>> cond2 ? expr2 :
>> cond3 ? expr3 :
>> default_expr
>> PHP's ?: operator originally associated right-to-left.
>> Newer versions of PHP require parentheses.
>
> I thought you were thinking of C++, where ? has the same precedence as
> assignment, while in C it has higher precedence. It does not make a
> lot of difference, and if you are writing an expression where it
> matters, then I think parentheses would be a good idea.
>
> <https://cppreference.com/c/language/operator_precedence>
> <https://cppreference.com/cpp/language/operator_precedence>
Hmm. I'm not sure I either follow or trust those tables.
Looking at the grammar in the C++ standard, there is a difference.
C has:
conditional-expression:
logical-OR-expression
logical-OR-expression ? expression : conditional-expression
while C++ has:
conditional-expression:
logical-or-expression
logical-or-expression ? expression : assignment-expression
But the difference isn't mentioned in the Compatibility annex of the C++
standard.
I'd be interested in seeing a conditional expression whose legality or
semantics differs between C and C++.
(Digression: I hate the fact that such a long and sometimes
informative thread has such a stupid subject header.)
--
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-02 11:38 +0200 |
| Message-ID | <10vm8au$3uus8$11@dont-email.me> |
| In reply to | #399604 |
On 2026-06-02 11:07, Keith Thompson wrote: > [...] > > (Digression: I hate the fact that such a long and sometimes > informative thread has such a stupid subject header.) And what did prevent you from changing it? :-} Janis
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-06-02 05:01 -0700 |
| Message-ID | <10vmgn2$2tjoi$1@kst.eternal-september.org> |
| In reply to | #399606 |
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
> On 2026-06-02 11:07, Keith Thompson wrote:
>> [...]
>> (Digression: I hate the fact that such a long and sometimes
>> informative thread has such a stupid subject header.)
>
> And what did prevent you from changing it? :-}
Futility. At best, I could start a new subthread. The existing
subject line would live on.
--
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 | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2026-06-02 12:39 +0000 |
| Subject | It is not futile to change the subject line (Was: this girl calls c ugly) |
| Message-ID | <10vmitc$o9ge$2@news.xmission.com> |
| In reply to | #399614 |
In article <10vmgn2$2tjoi$1@kst.eternal-september.org>, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: >Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes: >> On 2026-06-02 11:07, Keith Thompson wrote: >>> [...] >>> (Digression: I hate the fact that such a long and sometimes >>> informative thread has such a stupid subject header.) >> >> And what did prevent you from changing it? :-} > >Futility. At best, I could start a new subthread. The existing >subject line would live on. See. That wasn't so hard, was it? I maintain that there are several good reasons why changing the Subject line is a good thing. Many other people disagree with me, but I don't care about that. It is, as you imply, especially a good idea where, as here, the original (i.e., carried) Subject line is dumb. -- I shot a man on Fifth Aveneue, just to see him die.
[toc] | [prev] | [next] | [standalone]
Page 11 of 14 — ← Prev page 1 … 9 10 [11] 12 13 14 Next page →
Back to top | Article view | comp.lang.c
csiph-web