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 171 — 17 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: 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 "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
[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) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-02 15:39 -0700
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 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 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 6 of 9 — ← Prev page 1 2 3 4 5 [6] 7 8 9 Next page →
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-06-02 15:31 +0000 |
| Message-ID | <10vmt11$cev$4@reader1.panix.com> |
| In reply to | #399631 |
In article <mnCTR.17470$_BG8.10863@fx24.iad>,
Scott Lurndal <slp53@pacbell.net> wrote:
>cross@spitfire.i.gajendra.net (Dan Cross) writes:
>>In article <10vh1eo$1ei50$2@dont-email.me>, Bart <bc@freeuk.com> wrote:
>
>>
>>Both expressions above correspond to an AST like:
>>
>> ┌───────┐
>> │BinOp +│
>> └───────┘
>> ╱ ╲
>> ╱ ╲
>> ┌───────┐ ┌───────┐
>> │BinOp *│ │Sym `c`│
>> └───────┘ └───────┘
>> ╱ ╲
>> ╱ ╲
>> ┌───────┐ ┌───────┐
>> │Sym `a`│ │Sym `b`│
>> └───────┘ └───────┘
>
>Ah, the dangers of assuming everyone uses UTF-8.
Yeah, my bad. Here:
+-------+
|BinOp +|
+-------+
/ \
/ \
+-------+ +-------+
|BinOp *| |Sym `c`|
+-------+ +-------+
/ \
/ \
+-------+ +-------+
|Sym `a`| |Sym `b`|
+-------+ +-------+
(The original looks bad in my newsreader, too.)
- Dan C.
[toc] | [prev] | [next] | [standalone]
| 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 | 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]
Page 6 of 9 — ← Prev page 1 2 3 4 5 [6] 7 8 9 Next page →
Back to top | Article view | comp.lang.c
csiph-web