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 250 — 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: 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 "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 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 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 7 of 13 — ← Prev page 1 … 5 6 [7] 8 9 … 13 Next page →
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2026-05-31 10:15 -0400 |
| Message-ID | <10vhfp5$1iv7k$2@dont-email.me> |
| In reply to | #399548 |
On 2026-05-31 05:49, David Brown wrote: ... > Of course. Parentheses do not affect the generated code unless they > affect the semantics of the expression. (Some people think parentheses > affect the order of evaluation, but that is not the case for most > compilers.) I assume that last sentence is meant to apply only to parentheses which don't change the semantics? Otherwise it seems manifestly false.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-05-31 16:29 +0200 |
| Message-ID | <10vhgki$1j9hm$1@dont-email.me> |
| In reply to | #399555 |
On 31/05/2026 16:15, James Kuyper wrote: > On 2026-05-31 05:49, David Brown wrote: > ... >> Of course. Parentheses do not affect the generated code unless they >> affect the semantics of the expression. (Some people think parentheses >> affect the order of evaluation, but that is not the case for most >> compilers.) > > I assume that last sentence is meant to apply only to parentheses which > don't change the semantics? Otherwise it seems manifestly false. Yes. I thought I was quite clear in this, given that I wrote almost exactly that in the previous sentence (which you also quoted above).
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-05-31 03:45 -0700 |
| Message-ID | <10vh3gu$1fhs1$1@kst.eternal-september.org> |
| In reply to | #399545 |
Richard Harnden <richard.nospam@gmail.invalid> writes:
> On 31/05/2026 00:43, Keith Thompson wrote:
>> C's operator precedence rules are complicated and arguably flawed.
>> They could have been defined differently. A simpler set of rules,
>> with fewer levels,*might* have been better. I don't have any
>> concrete suggestions -- nor do I have any strong preferences.
>> I accept C's rules as they are. I would accept them if they had
>> been defined differently.
>
> Can't the compiler easily remove any parens that aren't necessary?
> So - just write complex expressions in a way that a human can most
> easily understand, it makes your intention clear and probable doesn't
> increase the size of the executable.
Compilers generally remove *all* parens, necessary or not.
The output of a compiler is assembly or machine code. You almost
certainly can't tell from the generated code whether the input was,
for example, `a * b + c`, `(a * b) + c`, or `(((a) * (b)) + (c))`.
--
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-05-31 04:02 -0700 |
| Message-ID | <10vh4g1$1fhs1$2@kst.eternal-september.org> |
| In reply to | #399551 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> Richard Harnden <richard.nospam@gmail.invalid> writes:
>> On 31/05/2026 00:43, Keith Thompson wrote:
>>> C's operator precedence rules are complicated and arguably flawed.
>>> They could have been defined differently. A simpler set of rules,
>>> with fewer levels,*might* have been better. I don't have any
>>> concrete suggestions -- nor do I have any strong preferences.
>>> I accept C's rules as they are. I would accept them if they had
>>> been defined differently.
>>
>> Can't the compiler easily remove any parens that aren't necessary?
>> So - just write complex expressions in a way that a human can most
>> easily understand, it makes your intention clear and probable doesn't
>> increase the size of the executable.
>
> Compilers generally remove *all* parens, necessary or not.
> The output of a compiler is assembly or machine code. You almost
> certainly can't tell from the generated code whether the input was,
> for example, `a * b + c`, `(a * b) + c`, or `(((a) * (b)) + (c))`.
I realize I missed part of the point of your question.
Adding parentheses to an expression in a way that yields
an equivalent expression almost certainly will not affect the
generated code. Any parentheses that "restate" the precedence
rules are only for the convenience of human readers.
Ideally, you should always use exactly the right number of
parentheses to optimize readability. But since humans are not
compilers, there is no one way to do that. I would probably
add parentheses to `x == y & z`, assuming I really wanted the
semantics of `(x == y) & z` for some reason, but I would find the
superfluous parentheses in `x + (y * z)` or `x = (y + z)` annoying.
(Almost as annoying as the poor choice of variable names.)
It's possible to have too few parentheses or too many.
--
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-05-31 09:04 -0700 |
| Message-ID | <86tsrnefac.fsf@linuxsc.com> |
| In reply to | #399545 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-05-31 18:11 +0100 |
| Message-ID | <10vhq39$1lpo1$1@dont-email.me> |
| In reply to | #399559 |
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? I don't think they are needed for the three main groups (unless you need to override the normal behaviour): * Arithmetic ops that everyone knows * Comparison ops which can be considered a single level (in C there are two, but they are rarely chained) * Logical AND/OR ops Most involved in coding should know the order of these groups and will know that AND takes precedence over OR because that is common. The leaves the following which are not used in the real world and which are diverse across languages: << >> & | ^ There it makes sense to use parentheses to make things clear when any of these appear, but only if there is more than one and they are mixed. I don't think that is particularly onerous to have to write, or too much clutter to read. I wouldn't call anyone stupid for using () in such cases; more pragmatic. There are some odd ones such as "." (not even considered a binary operator in some languages), and assignment, but these also commonly behave the same way across languages. And then there is ?: : a > b ? c : d # (a>b)?c:d a + b ? c : d # (a+b)?c:d The grouping of the first is probably what is intended. But in the second, the intent might have been (a+b)?c:d, or a+(b?c:c); we don't know for sure that the author didn't make a mistake or we don't know outselves. Another candidate for parentheses when there are leading or trailing binary ops involved.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-05-31 19:34 +0000 |
| Message-ID | <10vi2f8$ovl$2@reader1.panix.com> |
| In reply to | #399561 |
In article <10vhq39$1lpo1$1@dont-email.me>, Bart <bc@freeuk.com> 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? I was working on some code in a Unix-like kernel the other day where the original author wrote, `if ((a == 0) && (b == 1))` type expressions. The inner parentheses were totally superfluous. I removed them. As Tim wrote, there's obviously a balance to be struck between excessive verbosity and extreme concision. Over time, programmers working in a language (or a code base) do tend to internalize that some operations are more frequently misunderstood than others, and parenthesize accordingly. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-05-31 19:10 -0700 |
| Message-ID | <86zf1fc8oq.fsf@linuxsc.com> |
| In reply to | #399561 |
Bart <bc@freeuk.com> writes: > 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? The point of my comment is that either too many or too few is a subjective judgment, not an objective one. > And then there is ?: : > > a > b ? c : d # (a>b)?c:d > a + b ? c : d # (a+b)?c:d > > The grouping of the first is probably what is intended. But in the > second, the intent might have been (a+b)?c:d, or a+(b?c:c); we don't > know for sure that the author didn't make a mistake or we don't know > outselves. This example is so addlebrained that it's hard to imagine anyone being confused about it. Or that it's worth any expenditure of thought wondering what to do about people who are.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-06-01 11:12 +0100 |
| Message-ID | <10vjltg$255kd$1@dont-email.me> |
| In reply to | #399579 |
On 01/06/2026 03:10, Tim Rentsch wrote:
> Bart <bc@freeuk.com> writes:
>
>> 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?
>
> The point of my comment is that either too many or too few is a
> subjective judgment, not an objective one.
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, and I was extending
that to other examples in computing.
>> And then there is ?: :
>>
>> a > b ? c : d # (a>b)?c:d
>> a + b ? c : d # (a+b)?c:d
>>
>> The grouping of the first is probably what is intended. But in the
>> second, the intent might have been (a+b)?c:d, or a+(b?c:c); we don't
>> know for sure that the author didn't make a mistake or we don't know
>> outselves.
>
> This example is so addlebrained that it's hard to imagine anyone
> being confused about it. Or that it's worth any expenditure of
> thought wondering what to do about people who are.
I don't understand what the problem is with my examples. There can be
ambiguity in the mind of the person looking at such code as to how the
first terms are grouped.
These are more or less real examples, I just simplified the terms. Here
are some from MZLIB:
return (status == MZ_OK) ? MZ_BUF_ERROR : status;
return (pL == pE) ? (l_len < r_len) : (l < r);
sym = (match_dist < 512) ? s0 : s1;
return ((pState->m_last_status == TINFL_STATUS_DONE) &&
(!pState->m_dict_avail)) ? MZ_STREAM_END : MZ_OK;
I believe that in the first three, all parentheses are superflous, but
they are used anyway. Why is that?
(My preferences for ?: are that the whole thing is syntax, outside of
the precedence scheme, and that it has mandatory parentheses. That
second line would then look like this:
return (pL == pE ? l_len < r_len : l < r);
There are fewer parentheses in all, and less potential confusion. You
can even have assignments in each branch; they will not interfere with ?:.)
As for the last one, I haven't figured it out yet. But simplifying the
terms:
return ((a == b) && (!c)) ? d : e;
then the same applies: this could be:
return a == b && !c ? d : e;
However, I had to confirm this by comparing the ASTs for both.
I'd say that MZLIB is doing the right thing by not being too clever.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-06-01 12:36 +0200 |
| Message-ID | <10vjnbn$259m4$1@dont-email.me> |
| In reply to | #399585 |
On 01/06/2026 12:12, Bart wrote: > On 01/06/2026 03:10, Tim Rentsch wrote: >> Bart <bc@freeuk.com> writes: >> >>> 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? >> >> The point of my comment is that either too many or too few is a >> subjective judgment, not an objective one. > > 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, and I was extending > that to other examples in computing. > No, it is all still subjective. But the more levels of parentheses, the more consensus you are likely to get on the subjective opinions. To be "objective", you would have to have some kind of measure, with statistically significant results. If someone were to conduct a survey and measure the accuracy and thinking time for people to understand expressions written in different ways with different levels of parentheses, then there would be a basis for calling things "objective".
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-06-01 14:26 -0700 |
| Message-ID | <10vktel$2glfs$1@kst.eternal-september.org> |
| In reply to | #399585 |
Bart <bc@freeuk.com> writes:
[...]
> These are more or less real examples, I just simplified the
> terms. Here are some from MZLIB:
>
> return (status == MZ_OK) ? MZ_BUF_ERROR : status;
>
> return (pL == pE) ? (l_len < r_len) : (l < r);
>
> sym = (match_dist < 512) ? s0 : s1;
>
> return ((pState->m_last_status == TINFL_STATUS_DONE) &&
> (!pState->m_dict_avail)) ? MZ_STREAM_END : MZ_OK;
>
> I believe that in the first three, all parentheses are superflous, but
> they are used anyway. Why is that?
Obviously it's because the author of the code thought it was
clearer with the parentheses (or was working under a coding standard
written by someone who thought so). I don't think there are any
deeper conclusions to be drawn. I would have written most of them
differently, but it's not a big deal.
> (My preferences for ?: are that the whole thing is syntax, outside of
> the precedence scheme, and that it has mandatory parentheses. That
> second line would then look like this:
>
> return (pL == pE ? l_len < r_len : l < r);
>
> There are fewer parentheses in all, and less potential confusion. You
> can even have assignments in each branch; they will not interfere with
> ?:.)
But the precedence scheme *is* syntax. If you prefer to think of ?:
as something other than an operator, something that that doesn't
follow the same set of rules as other operators, and if that works
for you, then that's fine. But then how do you know that
return (pL == pE ? l_len < r_len : l < r);
means
return ((pL == pE) ? (l_len < r_len) : l < r);
and not
return (pL == (pE ? l_len < r_len : l < r));
?
I know that because I know that ?: is an operator that binds more
loosely than "==".
In any case, however you think about ?:, it's clear that
"pL == pE ? l_len < r_len : l < r" is an expression, and "return"
*is* outside of the precedence scheme. The outer parentheses are
superfluous but harmless. (Personally, I dislike parenthesizing
the expression in a return statement.)
[...]
--
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-04 02:34 -0700 |
| Message-ID | <86a4tad4xo.fsf@linuxsc.com> |
| In reply to | #399585 |
Bart <bc@freeuk.com> writes:
> On 01/06/2026 03:10, Tim Rentsch wrote:
>
>> Bart <bc@freeuk.com> writes:
>>
>>> 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?
>>
>> The point of my comment is that either too many or too few is a
>> subjective judgment, not an objective one.
>
> 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. Reaching consensus
on a question doesn't make the common view an objective one -- just
a commonly held one. Saying the Sun rises in the East is an
objective statement. Saying the temperature is too hot in the month
of September is not an objective statement, even if most people
think so.
>>> And then there is ?: :
>>>
>>> a > b ? c : d # (a>b)?c:d
>>> a + b ? c : d # (a+b)?c:d
>>>
>>> The grouping of the first is probably what is intended. But in the
>>> second, the intent might have been (a+b)?c:d, or a+(b?c:c); we don't
>>> know for sure that the author didn't make a mistake or we don't know
>>> outselves.
>>
>> This example is so addlebrained that it's hard to imagine anyone
>> being confused about it. Or that it's worth any expenditure of
>> thought wondering what to do about people who are.
>
> I don't understand what the problem is with my examples.
Here is a story from the earliest weeks of all of the time I have
been programming. In one of the first few programs I ever wrote
(and perhaps even the very first one), I had a statement like so:
x = alpha/beta*gamma
Of course the names here are made up, I don't remember the actual
names used. When x was printed out, it gave a value that was
much different from what I expected. What had happened was I had
unconsciously assumed, reasoning by analogy with written
mathematics, that the statement would be interpreted as
alpha
x = ------------
beta*gamma
After getting the program output back, and seeing the unexpected
result, someone explained to me that the statement was interpreted
as
x = (alpha/beta)*gamma
because that was how the language worked. Of course I was surprised
but I learned the rule and after that had no further problems with
how to read such expressions.
> There can be ambiguity in the mind of the person looking at such
> code as to how the first terms are grouped.
This statement illustrates the problem with examples that you give.
Not only is the presumed reader sort of arbitrarily naive, he or she
is apparently incapable of learning. Everyone who has ever learned
to program has had an experience of a program doing something other
than what was expected, because of a misunderstanding about how the
language works. When that happens, most people simply learn about
their misunderstanding and correct it. The readers in your examples
are like people who started programming after developing Alzheimer's
disease (and no offense meant to anyone afflicted with Alzheimer's).
Maybe there are such people, whether or not caused by a medical
condition, but it doesn't match most programmers' experience, and in
any case is not worth worrying about. If someone can't understand
the rules of the road they shouldn't be behind the wheel of a car.
If someone really can't learn the rules of expression syntax for the
language they are using, they should be advised to try a different
language, or perhaps give up programming altogether. It's silly to
worry about something that 999 people out of a 1000 (and the actual
numbers are undoubtedly much higher) are able to navigate without
difficulty. Yet the examples you give insist on focusing on the few
hopeless individuals. It shouldn't be a surprise that most people
don't share your concerns.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-06-04 12:40 +0100 |
| Message-ID | <10vro7t$bjmf$1@dont-email.me> |
| In reply to | #399673 |
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!
I'm sure you can trawl for some obscure languages where that expression
works differently, or where you can reassign priority or meaning to
those operators, but that is just being contrary for the sake of it.
> Reaching consensus
> on a question doesn't make the common view an objective one -- just
> a commonly held one.
So, the number of times in this group where I've been told that everyone
else disagrees with me about something so I must be wrong - this was
just your (pl) subjective opinion all along?
In the PL world then it is going to be mainly about subjective opinions!
There are few absolute truths.
But what about this example:
((((((a))))))
'Too many parentheses' is still subjective?
How about '((((a)))) using more parentheses than (a)'; that surely must
be objective?
> Here is a story from the earliest weeks of all of the time I have
> been programming. In one of the first few programs I ever wrote
> (and perhaps even the very first one), I had a statement like so:
>
> x = alpha/beta*gamma
>
> Of course the names here are made up, I don't remember the actual
> names used. When x was printed out, it gave a value that was
> much different from what I expected. What had happened was I had
> unconsciously assumed, reasoning by analogy with written
> mathematics, that the statement would be interpreted as
>
> alpha
> x = ------------
> beta*gamma
You will have quickly found out that PL syntax is not mathematics. For a
start, mathematics doesn't normally use '*', nor '/' for that matter.
Yes, there is a discrepancy with the precedences of divide and (implied)
multiply. However, a*a + b*b example didn't use divide.
(Note that C has its own problems in this area:
a = b/*p; // divide b by dereferenced pointer p
Here, /* also happens to start a block comment.)
> If someone really can't learn the rules of expression syntax for the
> language they are using, they should be advised to try a different
> language, or perhaps give up programming altogether.
It can be multiple languages, and they might want to write the same
expression the same way in each.
It could be no language: maybe its pseudo-code, or some unspecified
language in a forum which is not language-specific. They want anybody to
just understand it.
This is the scenerio I mentioned where you can risk not using
precedences when expressions involve "+ - * /", comparisons, and AND/OR
since generally these are treated sensibly by infix languages (even in
C, almost).
But operators such as '<< >> & ^ |' are treated more diversely. Here you
would be taking a bigger risk. You could label such code as 'C Syntax'
(if posting for example) but that is just being lazy.
> It's silly to
> worry about something that 999 people out of a 1000 (and the actual
> numbers are undoubtedly much higher) are able to navigate without
> difficulty. Yet the examples you give insist on focusing on the few
> hopeless individuals.
Are you saying that whoever wrote code like this:
crcu32 = (crcu32 >> 4) ^ s_crc32[(crcu32 & 0xF) ^ (b & 0xF)];
is needlessly worrying about the 99.9+% of the readership who you claim
will know C syntax rules precisely? That is, they would find this
version just as clear without any extra cognitive effort:
crcu32 = crcu32 >> 4 ^ s_crc32[crcu32 & 0xF ^ b & 0xF];
?
If so then you are hopelessly wrong.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-06-04 14:35 +0200 |
| Message-ID | <10vrred$74ie$1@dont-email.me> |
| In reply to | #399678 |
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. 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" ?
>
>> Reaching consensus
>> on a question doesn't make the common view an objective one -- just
>> a commonly held one.
>
> So, the number of times in this group where I've been told that everyone
> else disagrees with me about something so I must be wrong - this was
> just your (pl) subjective opinion all along?
Facts and opinions are different. You regularly get facts about C
wrong, and you are told you are wrong - that is objective. You
regularly give opinions that people disagree with, and are told they
disagree - that is subjective.
If you wrote, for example, that "a << b + c" is ambiguous in C, then you
would be factually and objectively wrong. If you wrote that it is
unclear, then you would be expressing a subjective opinion, and people
may or may not agree with you.
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.
>
> In the PL world then it is going to be mainly about subjective opinions!
> There are few absolute truths.
The programming language world is full of absolutely truths. The C
standards, for example, are full of facts about the C language. It is
not just a collection of guidelines or ideas for people to like or dislike.
>
> But what about this example:
>
> ((((((a))))))
>
> 'Too many parentheses' is still subjective?
Yes, obviously. "More parentheses than necessary" is objective, "too
many parentheses" is subjective. I expect most people will share the
same opinion, but it is still an opinion.
>
> How about '((((a)))) using more parentheses than (a)'; that surely must
> be objective?
Yes.
>
>> Here is a story from the earliest weeks of all of the time I have
>> been programming. In one of the first few programs I ever wrote
>> (and perhaps even the very first one), I had a statement like so:
>>
>> x = alpha/beta*gamma
>>
>> Of course the names here are made up, I don't remember the actual
>> names used. When x was printed out, it gave a value that was
>> much different from what I expected. What had happened was I had
>> unconsciously assumed, reasoning by analogy with written
>> mathematics, that the statement would be interpreted as
>>
>> alpha
>> x = ------------
>> beta*gamma
>
> You will have quickly found out that PL syntax is not mathematics. For a
> start, mathematics doesn't normally use '*', nor '/' for that matter.
It's not so much the symbols, as the layout. A mathematician would not
write "a÷b×c" either. They would write it in a way that makes the
intended precedence obvious to other mathematicians reading it, taking
into account the exact symbols used ("a.b" or "ab" might be considered
to bind tighter than "a×b"), the spacing, the position of the symbols on
the page, and - importantly - the context.
Programming can definitely be viewed as a sort of mathematics, but
writing code is not the same as writing mathematics.
>
> Yes, there is a discrepancy with the precedences of divide and (implied)
> multiply. However, a*a + b*b example didn't use divide.
>
> (Note that C has its own problems in this area:
>
> a = b/*p; // divide b by dereferenced pointer p
>
> Here, /* also happens to start a block comment.)
>
Here you are objectively wrong. C does not have a "problem" with this.
The parsing rules of the language are clear - often called "maximum
munch". The character sequence "/*" is the start of a comment, it is
not two separate operators.
You might personally have a problem with this. Whether you do or do not
is also an objective fact, but one that only you can judge. And you can
have a subjective opinion as to whether or not you like the rules of C here.
>
>
>> If someone really can't learn the rules of expression syntax for the
>> language they are using, they should be advised to try a different
>> language, or perhaps give up programming altogether.
>
> It can be multiple languages, and they might want to write the same
> expression the same way in each.
>
Sure.
I also don't think people should be required to learn all the details of
a language in order to use it. Indeed, for bigger languages (say, C++
or Python) it would be infeasible to learn everything. Exactly where
you draw the lines of what you need to know and what you can look up if
necessary will vary by person, and by the type of tasks they are doing
in a language.
> It could be no language: maybe its pseudo-code, or some unspecified
> language in a forum which is not language-specific. They want anybody to
> just understand it.
>
> This is the scenerio I mentioned where you can risk not using
> precedences when expressions involve "+ - * /", comparisons, and AND/OR
> since generally these are treated sensibly by infix languages (even in
> C, almost).
>
> But operators such as '<< >> & ^ |' are treated more diversely. Here you
> would be taking a bigger risk. You could label such code as 'C
> Syntax' (if posting for example) but that is just being lazy.
>
It is correct that details here vary more. Whether you think extra
parentheses should or should not be used is, however, a subjective
opinion. (My opinion is probably more in line with yours than Tim's
here - but it is still subjective.)
>> It's silly to
>> worry about something that 999 people out of a 1000 (and the actual
>> numbers are undoubtedly much higher) are able to navigate without
>> difficulty. Yet the examples you give insist on focusing on the few
>> hopeless individuals.
>
> Are you saying that whoever wrote code like this:
>
> crcu32 = (crcu32 >> 4) ^ s_crc32[(crcu32 & 0xF) ^ (b & 0xF)];
>
> is needlessly worrying about the 99.9+% of the readership who you claim
> will know C syntax rules precisely? That is, they would find this
> version just as clear without any extra cognitive effort:
>
> crcu32 = crcu32 >> 4 ^ s_crc32[crcu32 & 0xF ^ b & 0xF];
>
> ?
Tim did not write that. That example was not on the list of examples
you gave recently. The examples a couple of posts up in this branch
were a lot simpler. (That does not mean that Tim's "999 out of 1000"
figures are based on evidence.)
>
> If so then you are hopelessly wrong.
>
>
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-06-04 14:18 +0100 |
| Message-ID | <10vrtud$d8gc$1@dont-email.me> |
| In reply to | #399680 |
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... > > 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. The discssion seems to about what exactly is 'too many'. 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. 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. If this not 100% C-specific, than () are needed for both the last two examples, but not the first. You all know this. >> (Note that C has its own problems in this area: >> >> a = b/*p; // divide b by dereferenced pointer p >> >> Here, /* also happens to start a block comment.) >> > > Here you are objectively wrong. C does not have a "problem" with this. > The parsing rules of the language are clear - often called "maximum > munch". The character sequence "/*" is the start of a comment, it is > not two separate operators. This is where it falls down. It's very clearly a 'gotcha', and consequence of poorly thought-out design. That the behaviour is deterministic doesn't change that. >>> It's silly to >>> worry about something that 999 people out of a 1000 (and the actual >>> numbers are undoubtedly much higher) are able to navigate without >>> difficulty. Yet the examples you give insist on focusing on the few >>> hopeless individuals. >> >> Are you saying that whoever wrote code like this: >> >> crcu32 = (crcu32 >> 4) ^ s_crc32[(crcu32 & 0xF) ^ (b & 0xF)]; >> >> is needlessly worrying about the 99.9+% of the readership who you >> claim will know C syntax rules precisely? That is, they would find >> this version just as clear without any extra cognitive effort: >> >> crcu32 = crcu32 >> 4 ^ s_crc32[crcu32 & 0xF ^ b & 0xF]; >> >> ? > > Tim did not write that. What was the 'something' in "It's silly to worry about something that ..."? I assume it's people being unable to understand that second example. Yet I seee parenthese being used in such cases a LOT more than 0.1% of the time. 50% or more would be my guess. > That example was not on the list of examples > you gave recently. It was posted several times. (https://github.com/richgel999/miniz/blob/master/miniz.c line 81, second hit for '>>')
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-06-04 15:47 +0200 |
| Message-ID | <10vrvlq$2bg8$3@dont-email.me> |
| In reply to | #399682 |
On 2026-06-04 15:18, Bart wrote: > On 04/06/2026 13:35, David Brown wrote: >> [...] >> >> "(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'. It's a different thing, indeed. The suspicious keyword is "too many"; a valuation, and subjective. - It's no biggie to me, and in my other post I said that I'd just read it as a sloppy formulated variant of "more than necessary" or some such. So while inaccurately formulated I'm fine with that; I understood what you had intended to express. But the "completely", BTW, in your "is a completely different thing" is a cheap rhetorical exaggeration to obfuscate or diminish the issue with your valuating statement. (I don't like such primitive rhetoric moves.) > [...] > > I don't have the patience for such nonsense any more: > > * The () in '(a * b) + c' are generally unnecessary Right. > > * The () in 'a << (b + c)' are advisable Maybe, maybe not. (Depending on the involved persons, and on how they handle the cases shown below; whether they mix types in subexpressions or not.) > > * The () in '(a << b) + c)' are necessary if the intent is to have > what might be the more intuitive meaning. I've already written in some former post about _unnecessarily_ mixing different types in expressions. If you stay in such subexpressions with the same types you'll notice that the parentheses are unnecessary; the C-language's precedences have been sensibly chosen (in this case[*]). [*] And even if you add some of ^ | & it's still no problem, unless you have also any of the comparison operators in your expressions. Janis > [...]
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-06-04 15:57 +0200 |
| Message-ID | <10vs08j$2bg8$4@dont-email.me> |
| In reply to | #399685 |
On 2026-06-04 15:47, Janis Papanagnou wrote: > On 2026-06-04 15:18, Bart wrote: >>> [...] >> >> * The () in '(a << b) + c)' are necessary if the intent is to have >> what might be the more intuitive meaning. > > I've already written in some former post about _unnecessarily_ mixing > different types in expressions. To not cause misunderstandings here; by "different types" I meant the bit-logic and int-arithmetic, as explained in my mentioned former post. (The technical data types are of course both just some sort of 'int'.) > If you stay in such subexpressions with the same types you'll notice > that the parentheses are unnecessary; the C-language's precedences > have been sensibly chosen (in this case[*]). > > [*] And even if you add some of ^ | & it's still no problem, unless > you have also any of the comparison operators in your expressions. > > Janis > >> [...] >
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-06-04 16:27 +0200 |
| Message-ID | <10vs20g$d992$1@dont-email.me> |
| In reply to | #399682 |
On 04/06/2026 15:18, Bart wrote: > 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'. > Of course they are different things - albeit related things, rather than /completely/ different. One is a question of fact, the other a question of opinion, and they do not always coincide. It is a fact that "a << (b + c)" has more parentheses than needed. But I think we are both of the opinion that it does not have "too many" parentheses - it has an appropriate number of parentheses. > Sigh... > >> >> If you wrote, for example, that "a << b + c" is ambiguous in C, then you > > It is technically unambiguous in C. There is no "technically" about it. It is 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. I would not use the word "ambiguous" there - "unclear" would be more appropriate in the situation when someone does not know the C precedence levels. If you are given the expression and don't know it is in C, it's a very different matter - there are all kinds of things it could mean. In C++, it could mean concatenating two strings and passing the result to a output stream. In Forth, it could mean anything you like. With no context, the expression is not "ambiguous" because that implies that there is a number of reasonable interpretations - and without context, there is no limit to the interpretations. So while I entirely agree that "a << b + c" may not be clear, and may easily be misinterpreted, "ambiguous" is the wrong word to use. > > The discssion seems to about what exactly is 'too many'. No, it's an attempt to get you to understand the difference between "objective" and "subjective" - fact and opinion. I don't understand why you are having such a problem here. > > 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. 64 levels of nested parentheses is /factually/ and /objectively/ too many to be guaranteed supported by a conforming C compiler. It takes a far smaller number to be viewed as too many in the subjective opinion of a large proportion of people. > > I don't have the patience for such nonsense any more: > > * The () in '(a * b) + c' are generally unnecessary > Yes. They are unnecessary in C (that is a fact), and most people would not find them helpful in understanding the expression (that is a claimed fact, given without evidence, about people's opinions. It is my opinion that this claimed fact is true). > * The () in 'a << (b + c)' are advisable That is a subjective opinion. /I/ would generally advise including the parentheses here. Other people might have a different opinion. And people can have different opinions depending on the target audience. > > * The () in '(a << b) + c)' are necessary if the intent is to have > what might be the more intuitive meaning. The parentheses in "(a << b) + c" are necessary if the intent is to shift "a" by "b", and then add "c" to the result. That is fact, not opinion. Any discussion of "intuitive" is necessarily subjective. > > If this not 100% C-specific, than () are needed for both the last two > examples, but not the first. > > You all know this. > Do /you/ know what is fact and what is opinion here? Do you understand the difference, after spoon-feeding you these examples? And do you understand why it is important in a discussion to be able to make these distinctions? It matters, even if you and I would likely both want the parentheses mostly in the same places. > >>> (Note that C has its own problems in this area: >>> >>> a = b/*p; // divide b by dereferenced pointer p >>> >>> Here, /* also happens to start a block comment.) >>> >> >> Here you are objectively wrong. C does not have a "problem" with >> this. The parsing rules of the language are clear - often called >> "maximum munch". The character sequence "/*" is the start of a >> comment, it is not two separate operators. > > This is where it falls down. It's very clearly a 'gotcha', and > consequence of poorly thought-out design. It is neither a "gotcha", not a consequence of poor design. It does not "fall down". It is simply a minor consequence of the choice of operator syntax. Such an expression would occur rarely in code, and to be a "gotcha" it would need to be realistic for someone to write it, without spaces, and for their code to compile and be used without the mistake being noticed. Do you think that is in any way realistic? I do not. And to be "poor design", it needs to be something that is likely to cause problems (which it is not), or which requires significant effort to work around. Writing "a = b / *p;" is not challenging, and a lot of people prefer spaces around binary operators anyway. I'd say you were making a mountain out of a molehill, but I don't think it's as big as a molehill. > > That the behaviour is deterministic doesn't change that. > Of course it does. If some compilers treated it differently, then there might be a chance that someone wrote such code and got the expected results from the tool they were using, even though it was treated differently by other tools. >>>> It's silly to >>>> worry about something that 999 people out of a 1000 (and the actual >>>> numbers are undoubtedly much higher) are able to navigate without >>>> difficulty. Yet the examples you give insist on focusing on the few >>>> hopeless individuals. >>> >>> Are you saying that whoever wrote code like this: >>> >>> crcu32 = (crcu32 >> 4) ^ s_crc32[(crcu32 & 0xF) ^ (b & 0xF)]; >>> >>> is needlessly worrying about the 99.9+% of the readership who you >>> claim will know C syntax rules precisely? That is, they would find >>> this version just as clear without any extra cognitive effort: >>> >>> crcu32 = crcu32 >> 4 ^ s_crc32[crcu32 & 0xF ^ b & 0xF]; >>> >>> ? >> >> Tim did not write that. > > What was the 'something' in "It's silly to worry about something that ..."? > My mind-reading skills are not that well developed. > I assume it's people being unable to understand that second example. He did not say he was talking about those examples. Given that the "crc" examples are more distant in the Usenet thread, it seems a stretch to assume he was referring to them, rather than to the code examples you had just given. (It would, perhaps, have been helpful if Tim had not snipped those examples.) > > Yet I seee parenthese being used in such cases a LOT more than 0.1% of > the time. 50% or more would be my guess. > > >> That example was not on the list of examples you gave recently. > > > It was posted several times. > > (https://github.com/richgel999/miniz/blob/master/miniz.c line 81, second > hit for '>>') > >
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-06-04 16:46 +0100 |
| Message-ID | <10vs6kc$fsd2$1@dont-email.me> |
| In reply to | #399688 |
On 04/06/2026 15:27, David Brown wrote:
> On 04/06/2026 15:18, Bart wrote:
>>> 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'.
>
> Of course they are different things - albeit related things, rather
> than /completely/ different. One is a question of fact, the other a
> question of opinion, and they do not always coincide.
>
> It is a fact that "a << (b + c)" has more parentheses than needed. But
> I think we are both of the opinion that it does not have "too many"
> parentheses - it has an appropriate number of parentheses.
So saying 'too many' of something will be a subjective opinion? OK, so
let's try compiling this bit of C:
void F(int, int);
int main() {
F(1, 2, 3);
}
8 out of 9 compilers reported 'Too many arguments'.
According to you, that's only their subjective opinion, not an objective
fact?
I tried a version in Go for good measure; it also used 'Too many'.
I think we'll leave it here.
>
>> Sigh...
>>
>>>
>>> If you wrote, for example, that "a << b + c" is ambiguous in C, then you
>>
>> It is technically unambiguous in C.
>
> There is no "technically" about it. It is 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.
>
> I would not use the word "ambiguous" there - "unclear" would be more
> appropriate in the situation when someone does not know the C precedence
> levels.
What would think if you saw this:
r << 16 + g << 8 + b
Did they really mean 'r << (16 + g) << (8 + b)' ?
> No, it's an attempt to get you to understand the difference between
> "objective" and "subjective" - fact and opinion. I don't understand why
> you are having such a problem here.
See my example above with compilers. Maybe you can give all their
authors the same patronising talk.
>> * The () in '(a << b) + c)' are necessary if the intent is to have
>> what might be the more intuitive meaning.
>
> The parentheses in "(a << b) + c" are necessary if the intent is to
> shift "a" by "b", and then add "c" to the result. That is fact, not
> opinion. Any discussion of "intuitive" is necessarily subjective.
Intuitive because here << performs the same scaling function as multiply:
a << b is the same as a * 2**b
a * b is the same as a << log2(b) when b is a power of two
(or thereabouts!)
The point is: they naturally belong together.
Given 'a * 8 + b' or 'a << 3 + b', it is desirable to freely convert one
to the other without having to restructure the parentheses.
>>>> a = b/*p; // divide b by dereferenced pointer p
>> This is where it falls down. It's very clearly a 'gotcha', and
>> consequence of poorly thought-out design.
>
> It is neither a "gotcha", not a consequence of poor design. It does not
> "fall down". It is simply a minor consequence of the choice of operator
> syntax. Such an expression would occur rarely in code, and to be a
> "gotcha" it would need to be realistic for someone to write it, without
> spaces, and for their code to compile and be used without the mistake
> being noticed. Do you think that is in any way realistic? I do not.
It's a poor show. This program:
#include <stdio.h>
int main() {
int a=1, b=200, c=3, d=77;
int *p = &d;
a = b / *p;
c = d /* comment*/ + 5;
printf("%d\n", a);
printf("%d\n", c);
}
displays 2 82. If that space between / and * is lost, it still compiles,
but displays 205 3.
Yes, it's unlikely, but so what? You don't dismess such issues in a PL
by crossing your fingers and suggesting it's unlikely to come up.
There are actually other issues associated with /**/ comments; here
someone forgot to terminate the first comment:
puts("one"); /* comment 1
puts("two"); /* commmet 2 */
puts("three"); /* comment 3 */
The middle line is silently elided. This is one with // comments:
puts("one"); // file c:\cx\
puts("two");
puts("three");
Again, the middle line is commented out.
I'd say C comments have a few issues. That the standard explains exactly
how they work doesn't help.
> And to be "poor design", it needs to be something that is likely to
> cause problems
But you would choose not to have these issues in a new language.
>> What was the 'something' in "It's silly to worry about something
>> that ..."?
>>
>
> My mind-reading skills are not that well developed.
It didn't stop you giving an opinion about what you thought he meant!
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-06-04 20:15 +0200 |
| Message-ID | <10vsfc7$fm4o$2@dont-email.me> |
| In reply to | #399690 |
On 2026-06-04 17:46, Bart wrote:
> On 04/06/2026 15:27, David Brown wrote:
>> On 04/06/2026 15:18, Bart wrote:
>
>>>> 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'.
>>
>> Of course they are different things - albeit related things, rather
>> than /completely/ different. One is a question of fact, the other a
>> question of opinion, and they do not always coincide.
>>
>> It is a fact that "a << (b + c)" has more parentheses than needed.
>> But I think we are both of the opinion that it does not have "too
>> many" parentheses - it has an appropriate number of parentheses.
>
> So saying 'too many' of something will be a subjective opinion?
Oh, I feel guilty! - My hint on the _suspicious_ "too many" keyword
got (wrongly!) *generalized* as always being a subjective valuation
in all cases. - I apologize to have contributed to your confusion.
> OK, so let's try compiling this bit of C:
>
> void F(int, int);
>
> int main() {
> F(1, 2, 3);
> }
>
> 8 out of 9 compilers reported 'Too many arguments'.
And that is correct in _this semantic context_. - The rules require
two integers and providing three is too many of course; that's a fact.
In x=(((((((a))))))); the rules allow the parenthesis, but they are
neither required nor do they seem to serve any sensible purpose. Here
the "two many" (w.r.t. clearness of the expression) is a subjectively
common and sensible valuation.
> [...]
>
> I think we'll leave it here.
(I'd have hoped we could leave all that from the beginning!)
> [...]
>>> * The () in '(a << b) + c)' are necessary if the intent is to have
>>> what might be the more intuitive meaning.
>>
>> The parentheses in "(a << b) + c" are necessary if the intent is to
>> shift "a" by "b", and then add "c" to the result. That is fact, not
>> opinion. Any discussion of "intuitive" is necessarily subjective.
>
> Intuitive because here << performs the same scaling function as multiply:
>
> a << b is the same as a * 2**b
>
> a * b is the same as a << log2(b) when b is a power of two
> (or thereabouts!)
("or thereabouts"? - You are squirming and lacking the precision that
would be necessary here for a sensual consideration of the concepts.)
>
> The point is: they naturally belong together.
You can express the shift by arithmetic, yes. And you can express some
*special cases* of arithmetic by the shifts. - That doesn't imply that
you should thus mix types. Rather the opposite; if you stay within the
respective operation class the precedences of the C-languages support
you with no parentheses necessary while staying withing the respective
operation classes.
The point, is if you operate on bits you should best use bit-operations
and if you do arithmetic you should best use arithmetic operations.
(The word "best" expresses my personal valuation based on explanations
I already gave before and repeat below - it may be worth to think about
that for a moment before continuing.)
>
> Given 'a * 8 + b' or 'a << 3 + b', it is desirable to freely convert one
> to the other without having to restructure the parentheses.
No, it's undesirable if you want to express a cleanly typed expression.
If (for some reason) you don't care about a clear separation *then* you
might *need*, and probably *should* use parentheses to reestablish the
clearness that you gave up in the first place by mixing the arithmetic
and bit type operations.
I suggest if you intend arithmetic write a * 8 + b (not a * 8 | b ),
if you intend bit operations write u << 3 | v (unless there's reason)
and you need no parentheses. So that then, in the cases where the shift
value is to be calculated, you may write u << a + b
and also need no parentheses (but you can of course use them if you're
unsure about readers' understanding or if you as programmer are unsure
about it despite existing precedence tables and given explanations).[*]
The precedences in "C" are sensibly defined in all those cases.
Janis
[*] Note that I used different letters to enhance comprehensibility for
you. (Where you used the same names because you haven't been capable of
recognizing the point and throw all in one bag thus missing the point
of differentiating the two operation classes.)
> [...]
[toc] | [prev] | [next] | [standalone]
Page 7 of 13 — ← Prev page 1 … 5 6 [7] 8 9 … 13 Next page →
Back to top | Article view | comp.lang.c
csiph-web