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 8 of 9 — ← Prev page 1 2 3 4 5 6 7 [8] 9 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-06-02 09:17 +0200 |
| Message-ID | <10vm01d$2ne3j$3@dont-email.me> |
| In reply to | #399593 |
On 01/06/2026 22:04, Bart wrote:
> On 01/06/2026 19:48, Dan Cross wrote:
>> In article <10vjsg2$259m3$3@dont-email.me>,
>
>>> Names for magic constants can be good, but they are not always helpful -
>>> if the magic number is only used once, its definition is far from its
>>> use, and it is polluting the global name space, then it can be a lot
>>> better to simply use the number directly and add a comment at the point
>>> of use. But the shift-and-mask constants could be replaced by either a
>>> struct with bit-fields, or inline functions for field extractions, or at
>>> separate local variables for the extracted fields.
>>
>> I don't mind some magic: the shift constants and the masks, for
>> instance, are fine. But the magic 527, 259, 23, and 33, and why
>> the subsequent values are shifted right by 6, could be better
>> explained by naming those constants.
>>
>> Btw, with respect to this specific algorithm, I looked them up,
>> and they seem to be empirically discovered lore, though derived
>> from a relatively standard algorithm for projection of a
>> discrete value into a larger space. This stack overflow page
>> has some details:
>> https://stackoverflow.com/questions/2442576/how-does-one-convert-16-
>> bit-rgb565-to-24-bit-rgb888
>>
>> Anyway, I don't think the constants have to be defined far away
>> from the code; I'd be happy with a local `const uint32_t FOO`,
>> though in this case it should probably just be a comment.
>> Here's my offering:
>>
>> // Converts a 16-bit RGB16 (5-6-5) value to an ARGB32
>> // ("RGBA8888") value.
>> static inline uint32_t
>> rgb16_to_argb(uint16_t color)
>> {
>> const uint32_t blue5 = (color >> 0) & 0x1F;
>> const uint32_t green6 = (color >> 5) & 0x3F;
>> const uint32_t red5 = (color >> 11) & 0x1F;
>>
>> // Map from a 5 or 6 bit space into an 8 bit space. A
>> // 5-bit number has 32 possibilities; a 6 bit number
>> // has 64. We can calculate the projected 8-bit
>> // value for a k-bit number v, we can use the formula,
>> // v_8 = (v*2^8-1 + (k - 1)/2)/(2^k-1), or
>> // (v*255 + 15)/31 (for k=5) or (v*255 + 31)/63 (for
>> // k=6.
>> //
>> // To remove division by a prime and turn it into a
>> // shift, the constants below were empirically
>> // discovered to generate good results. See
>> // https://stackoverflow.com/questions/2442576/how-does-one-
>> convert-16-bit-rgb565-to-24-bit-rgb888
>> // for details.
>> const uint32_t blue = (blue5 * 527 + 23) >> 6;
>> const uint32_t green = (green6 * 259 + 33) >> 6;
>> const uint32_t red = (red5 * 527 + 23) >> 6;
>> const uint32_t alpha = 0xFF000000;
>>
>> return blue | (green << 8) | (red << 16) | alpha;
>> }
>>
>> It's longer, yes, but I'd argue it's much easier to understand.
>> On my compiler, it generates almost identical code, except that
>> some instructions are in a different order.
>
> The speed probably isn't that important. This can be table-driven: you
> use those formulae once to populate some tables (and with the shifts
> built-in). Then the routine can be simplified to this:
>
>
> uint32_t rgb16_to_argb_bc(uint16_t color) {
> const uint32_t blue5 = (color >> 0) & 0x1F;
> const uint32_t green6 = (color >> 5) & 0x3F;
> const uint32_t red5 = (color >> 11) & 0x1F;
>
> return bluetab[blue5] | greentab[green6] | redtab[red5] |
> 0xFF000000;
> }
>
> On a test I did (one billion conversions cycling over 1M precalculated
> random 16-bit numbers), the table version was twice as fast. Maybe a bit
> faster if the Alpha value is pre-added to the red-table.
>
> (Results were merely summed, but if writing into a new buffer, then
> memory access is probably more dominant.)
Such timing results are, as they stand, totally useless - the best
choice of algorithm is entirely dependent on the target device,
tradeoffs for speed and code/table space, and on how the code is used in
practice.
It is absolutely true that a table-based approach can give faster
results. (And there's no doubt that your table code here is vastly
clearer than the original macro.) On some microcontrollers, avoiding
the multiplications would give code that is an order of magnitude
faster. On others, table lookup would be a lot slower.
So it is definitely worth thinking about alternative approaches such as
this, but testing on a PC gives very little information about real-world
speed.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-06-02 09:09 +0200 |
| Message-ID | <10vlvie$2ne3j$2@dont-email.me> |
| In reply to | #399592 |
On 01/06/2026 20:48, Dan Cross wrote:
> In article <10vjsg2$259m3$3@dont-email.me>,
> David Brown <david.brown@hesbynett.no> wrote:
>> On 01/06/2026 13:04, Dan Cross wrote:
>>> In article <10vjdn8$22tgu$1@dont-email.me>,
>>> David Brown <david.brown@hesbynett.no> wrote:
>>>> On 31/05/2026 19:11, Bart wrote:
>>>>> [snip]
>>>>> Actual examples of too many parentheses?
>>>>
[Snipping the LISP stuff - fun, but OT and not really relevant to the
thread branch. And I have never used the language.]
>>>
>>> I see code like this all the time; usually it comes from
>>> hardware vendors (I take it this was from a BSP or something
>>> similar?). I often wonder about vendor programming standards
>>> when I run across things like it.
>>
>> Yes, this was from a hardware vendor (who shall remain nameless to
>> protect the guilty - not that I have found other vendors to be much
>> better). They have a tendency to be obsessed with MISRA, with sticking
>> to C90, and with filling headers with huge Doxygen templates giving no
>> information and obscuring the code. (I'm fine with Doxygen comments
>> that actually add useful information, but not a dozen lines repeating
>> the names and types from a function signature.)
>
> Yes. I see all of this, and it mystifies me; I have seen how
> excessive abstraction can lead to opaque code, but many times
> hardware people go in the opposite direction, and one hardly
> ever sees useful abstraction; for example, often the same code
> sequence could be trivially extracted into a function, but it is
> instead repeated multiple times, inline.
>
Indeed. There is just /so/ much that is done badly in these SDK's - I
am not going to go into details as it would take all day. I get the
impression that software libraries are very much an afterthought for
most microcontroller design groups - I don't think they ever bother
talking to developers who will use them. In fact, I don't think they
talk much to the software folks when designing the microcontrollers either.
Sometimes, however, they do have abstractions - sometimes multiple
layers of HALs ("Hardware Abstraction Layer"), drivers, interfaces, etc.
Each layer has a completely different way of viewing things - one will
use #define'd constants for everything, another will use a struct with
30 fields passed as a pointer in order to turn a GPIO pin on or off, and
the next layer will use a macro TURN_GPIO_PIN_A14_ON. When you have
figured out which API you are expected to use, toggling a GPIO leads to
a half-dozen nested calls (not including macros) up and down theses
stacks when all the hardware needs is a single write to a particular
register. And if you are really lucky, a global HAL_LOCK_MUTEX is
acquired and released along the way.
The most extreme example I saw was working on a very small 8-bit
microcontroller - 2 KB of code flash. I wanted to use the ADC, and
thought I'd save reading the datasheet and reference manual by using the
"wizard" and SDK. The result needed 4 KB of flash - twice what the chip
had - and half of its ram. I looked in the manual and got the same
results I needed with a single line of C code that compiled to just one
assembly instruction.
(Time to cut the rant short.)
>>>
>>> Not to mention symbolic names for the magic constants. :-/
>>
>> Names for magic constants can be good, but they are not always helpful -
>> if the magic number is only used once, its definition is far from its
>> use, and it is polluting the global name space, then it can be a lot
>> better to simply use the number directly and add a comment at the point
>> of use. But the shift-and-mask constants could be replaced by either a
>> struct with bit-fields, or inline functions for field extractions, or at
>> separate local variables for the extracted fields.
>
> I don't mind some magic: the shift constants and the masks, for
> instance, are fine. But the magic 527, 259, 23, and 33, and why
> the subsequent values are shifted right by 6, could be better
> explained by naming those constants.
>
Agreed - those are the "magic" ones, and need explaining (or perhaps
calculating, at compile time, from something that makes sense to the
reader and maintainer).
> Btw, with respect to this specific algorithm, I looked them up,
> and they seem to be empirically discovered lore, though derived
> from a relatively standard algorithm for projection of a
> discrete value into a larger space. This stack overflow page
> has some details:
> https://stackoverflow.com/questions/2442576/how-does-one-convert-16-bit-rgb565-to-24-bit-rgb888
>
A URL in comments in the code would be a lot better than just the numbers.
> Anyway, I don't think the constants have to be defined far away
> from the code; I'd be happy with a local `const uint32_t FOO`,
> though in this case it should probably just be a comment.
> Here's my offering:
>
> // Converts a 16-bit RGB16 (5-6-5) value to an ARGB32
> // ("RGBA8888") value.
> static inline uint32_t
> rgb16_to_argb(uint16_t color)
> {
> const uint32_t blue5 = (color >> 0) & 0x1F;
> const uint32_t green6 = (color >> 5) & 0x3F;
> const uint32_t red5 = (color >> 11) & 0x1F;
>
> // Map from a 5 or 6 bit space into an 8 bit space. A
> // 5-bit number has 32 possibilities; a 6 bit number
> // has 64. We can calculate the projected 8-bit
> // value for a k-bit number v, we can use the formula,
> // v_8 = (v*2^8-1 + (k - 1)/2)/(2^k-1), or
> // (v*255 + 15)/31 (for k=5) or (v*255 + 31)/63 (for
> // k=6.
> //
> // To remove division by a prime and turn it into a
> // shift, the constants below were empirically
> // discovered to generate good results. See
> // https://stackoverflow.com/questions/2442576/how-does-one-convert-16-bit-rgb565-to-24-bit-rgb888
> // for details.
> const uint32_t blue = (blue5 * 527 + 23) >> 6;
> const uint32_t green = (green6 * 259 + 33) >> 6;
> const uint32_t red = (red5 * 527 + 23) >> 6;
> const uint32_t alpha = 0xFF000000;
>
> return blue | (green << 8) | (red << 16) | alpha;
> }
>
> It's longer, yes, but I'd argue it's much easier to understand.
> On my compiler, it generates almost identical code, except that
> some instructions are in a different order.
Yes, that would be vastly better. (I would still prefer to have
different named types for colours in the different encoding schemes.)
>
>>> This is exactly the sort of thing that, as you point out, a
>>> `static inline` function is far better suited for. Some code
>>> bases don't want to use them for a variety of reasons, usually
>>> compatibility concerns with older code, compilers, or language
>>> standards. Some variants of Unix, for instance, worry about
>>> header compatibility with C90 [and in some cases K&R C] code.
>>
>> Indeed. But even if they don't want to use "inline", a static function
>> is better - the compiler will do the inlining anyway (if it makes sense
>> according to its heuristics).
>
> Assuming the compiler they're working with is known to do so,
> then I agree.
>
If a compiler is not capable of inlining static functions without them
being labelled "inline", then you are unlikely to get efficient results
anyway. (Or the user has not enabled optimisation, and again cannot
expect efficient results.) I don't see the point in pandering to poorly
optimising compilers (including good compilers with optimisation
disabled) in order to produce marginally less big and slow code. There
was a time when a good optimising compiler was a significant investment
and not always within the budget for a project, but such times are far
in the past. I can understand that some developers are hamstrung by
daft C90 restrictions, but I have little sympathy for people wanting
good results from poor tools.
(The exception, perhaps, is people who have to use Microchip development
tools.)
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-06-02 12:07 +0000 |
| Message-ID | <10vmh2e$b44$1@reader1.panix.com> |
| In reply to | #399602 |
In article <10vlvie$2ne3j$2@dont-email.me>,
David Brown <david.brown@hesbynett.no> wrote:
>On 01/06/2026 20:48, Dan Cross wrote:
>> In article <10vjsg2$259m3$3@dont-email.me>,
>> David Brown <david.brown@hesbynett.no> wrote:
>>> On 01/06/2026 13:04, Dan Cross wrote:
>>>> In article <10vjdn8$22tgu$1@dont-email.me>,
>>>> David Brown <david.brown@hesbynett.no> wrote:
>>>>> On 31/05/2026 19:11, Bart wrote:
>>>>>> [snip]
>>>>>> Actual examples of too many parentheses?
>>>>>
>
>[Snipping the LISP stuff - fun, but OT and not really relevant to the
>thread branch. And I have never used the language.]
Fair!
>>>> [snip]
>>>> I see code like this all the time; usually it comes from
>>>> hardware vendors (I take it this was from a BSP or something
>>>> similar?). I often wonder about vendor programming standards
>>>> when I run across things like it.
>>>
>>> Yes, this was from a hardware vendor (who shall remain nameless to
>>> protect the guilty - not that I have found other vendors to be much
>>> better). They have a tendency to be obsessed with MISRA, with sticking
>>> to C90, and with filling headers with huge Doxygen templates giving no
>>> information and obscuring the code. (I'm fine with Doxygen comments
>>> that actually add useful information, but not a dozen lines repeating
>>> the names and types from a function signature.)
>>
>> Yes. I see all of this, and it mystifies me; I have seen how
>> excessive abstraction can lead to opaque code, but many times
>> hardware people go in the opposite direction, and one hardly
>> ever sees useful abstraction; for example, often the same code
>> sequence could be trivially extracted into a function, but it is
>> instead repeated multiple times, inline.
>
>Indeed. There is just /so/ much that is done badly in these SDK's - I
>am not going to go into details as it would take all day. I get the
>impression that software libraries are very much an afterthought for
>most microcontroller design groups - I don't think they ever bother
>talking to developers who will use them. In fact, I don't think they
>talk much to the software folks when designing the microcontrollers either.
I think that's exactly what happens: the uCtlr companies don't
have robust software development organizations, and it's seen as
a side-bag to their core business. The same is true for the
bigger hardware vendors, as well (lookin' at you, Intel). Cue
the famous story about Fred Brooks throwing Gene Amdahl out of
his office until the latter came with with a hardware design for
the IBM 360 with byte addressing and power of two widths for
primitive data types.
>Sometimes, however, they do have abstractions - sometimes multiple
>layers of HALs ("Hardware Abstraction Layer"), drivers, interfaces, etc.
> Each layer has a completely different way of viewing things - one will
>use #define'd constants for everything, another will use a struct with
>30 fields passed as a pointer in order to turn a GPIO pin on or off, and
>the next layer will use a macro TURN_GPIO_PIN_A14_ON. When you have
>figured out which API you are expected to use, toggling a GPIO leads to
>a half-dozen nested calls (not including macros) up and down theses
>stacks when all the hardware needs is a single write to a particular
>register. And if you are really lucky, a global HAL_LOCK_MUTEX is
>acquired and released along the way.
Yes. The way one boots an AMD server SoC, for instance,
requires shipping a bunch of binary data structures around to
little microcontrollers spread across a bunch of AXI buses, that
are then responsible for things like configuring PCIe links and
enumerating IO buses and so on. The vendor code for doing this
is opaque, at best. For example,
https://github.com/openSIL/openSIL/blob/turin_poc/xUSL/Nbio/Brh/NbioPcieComplexDataBrh.c
(and that's a cleaned-up version).
>[snip color mapping code]
>
>Yes, that would be vastly better. (I would still prefer to have
>different named types for colours in the different encoding schemes.)
I'll see your named types and raise you a bitfield struct. The
shifting and masking is superfluous.
>>>> This is exactly the sort of thing that, as you point out, a
>>>> `static inline` function is far better suited for. Some code
>>>> bases don't want to use them for a variety of reasons, usually
>>>> compatibility concerns with older code, compilers, or language
>>>> standards. Some variants of Unix, for instance, worry about
>>>> header compatibility with C90 [and in some cases K&R C] code.
>>>
>>> Indeed. But even if they don't want to use "inline", a static function
>>> is better - the compiler will do the inlining anyway (if it makes sense
>>> according to its heuristics).
>>
>> Assuming the compiler they're working with is known to do so,
>> then I agree.
>
>If a compiler is not capable of inlining static functions without them
>being labelled "inline", then you are unlikely to get efficient results
>anyway. (Or the user has not enabled optimisation, and again cannot
>expect efficient results.) I don't see the point in pandering to poorly
>optimising compilers (including good compilers with optimisation
>disabled) in order to produce marginally less big and slow code. There
>was a time when a good optimising compiler was a significant investment
>and not always within the budget for a project, but such times are far
>in the past. I can understand that some developers are hamstrung by
>daft C90 restrictions, but I have little sympathy for people wanting
>good results from poor tools.
>
>(The exception, perhaps, is people who have to use Microchip development
>tools.)
It's not just because the optimizer is bad or the developers are
obtuse. Sometimes it's a deliberate decision to support
external tooling, like a debugger or tracing program or similar.
Some projects deliberately tolerate slower code for that.
Moreover, on large code bases, with long life spans, upgrading a
compiler is a significant investment. Almost invariably the
code has UB somewhere (I work on a code base that has been
evolving since before ANSI C; out of about 11 million lines,
there's lots of code that can be considered "legacy" in it).
From a business standpoint, it's not worth the time or
engineering resources required to go find all of it and make it
strictly conforming; from a technical standpoint, it may not
always be possible to do so anyway (though other superset
standards, like POSIX, are another matter), and in other cases
the resulting obfuscation to meet much stricter demands of ISO C
has been deemed, rightly or wrongly, as simply not worth it. It
may not ideal, but them's the breaks.
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-06-02 14:37 +0200 |
| Message-ID | <10vmipn$2ruaa$2@dont-email.me> |
| In reply to | #399616 |
On 02/06/2026 14:07, Dan Cross wrote: > In article <10vlvie$2ne3j$2@dont-email.me>, > David Brown <david.brown@hesbynett.no> wrote: >> On 01/06/2026 20:48, Dan Cross wrote: >>> In article <10vjsg2$259m3$3@dont-email.me>, >>> David Brown <david.brown@hesbynett.no> wrote: >>>> On 01/06/2026 13:04, Dan Cross wrote: >>>>> In article <10vjdn8$22tgu$1@dont-email.me>, >>>>> David Brown <david.brown@hesbynett.no> wrote: >>>>>> On 31/05/2026 19:11, Bart wrote: >>>>>>> [snip] >> [snip color mapping code] >> >> Yes, that would be vastly better. (I would still prefer to have >> different named types for colours in the different encoding schemes.) > > I'll see your named types and raise you a bitfield struct. The > shifting and masking is superfluous. Sure. "Named types" does not preclude bit-fields. I'd prefer some kind of struct, for type safety, but even a typedef is better than nothing. And when you have a struct for something like this, bit-fields are an obvious choice (at least for code that doesn't have to be portable to different endian systems). > >>>>> This is exactly the sort of thing that, as you point out, a >>>>> `static inline` function is far better suited for. Some code >>>>> bases don't want to use them for a variety of reasons, usually >>>>> compatibility concerns with older code, compilers, or language >>>>> standards. Some variants of Unix, for instance, worry about >>>>> header compatibility with C90 [and in some cases K&R C] code. >>>> >>>> Indeed. But even if they don't want to use "inline", a static function >>>> is better - the compiler will do the inlining anyway (if it makes sense >>>> according to its heuristics). >>> >>> Assuming the compiler they're working with is known to do so, >>> then I agree. >> >> If a compiler is not capable of inlining static functions without them >> being labelled "inline", then you are unlikely to get efficient results >> anyway. (Or the user has not enabled optimisation, and again cannot >> expect efficient results.) I don't see the point in pandering to poorly >> optimising compilers (including good compilers with optimisation >> disabled) in order to produce marginally less big and slow code. There >> was a time when a good optimising compiler was a significant investment >> and not always within the budget for a project, but such times are far >> in the past. I can understand that some developers are hamstrung by >> daft C90 restrictions, but I have little sympathy for people wanting >> good results from poor tools. >> >> (The exception, perhaps, is people who have to use Microchip development >> tools.) > > It's not just because the optimizer is bad or the developers are > obtuse. Sometimes it's a deliberate decision to support > external tooling, like a debugger or tracing program or similar. > Some projects deliberately tolerate slower code for that. That's fine - you are knowingly picking a different tradeoff. > > Moreover, on large code bases, with long life spans, upgrading a > compiler is a significant investment. In any given project, I consider the toolchain as part of the project. I don't upgrade or replace it without very good reason. If I pull an old project out of its mothballs to make a change, the first thing I do is a clean rebuild and compare the binary to the one stored with the project, to be sure that everything builds cleanly and identically. (My record for doing this was almost exactly 20 years between code changes - and that code was in C90. But the compiler was happy to do inlining optimisations without the "inline" keyword.) > Almost invariably the > code has UB somewhere (I work on a code base that has been > evolving since before ANSI C; out of about 11 million lines, > there's lots of code that can be considered "legacy" in it). > From a business standpoint, it's not worth the time or > engineering resources required to go find all of it and make it > strictly conforming; from a technical standpoint, it may not > always be possible to do so anyway (though other superset > standards, like POSIX, are another matter), and in other cases > the resulting obfuscation to meet much stricter demands of ISO C > has been deemed, rightly or wrongly, as simply not worth it. It > may not ideal, but them's the breaks. > Fair enough. I am a little spoiled in that most of the code I work with, I wrote. But that is less true now than it used to be. In the old days, I would rarely need anything from the standard library and nothing from microcontroller vendors or third parties. (Before that, I would typically use assembly for microcontrollers, and then everything was my own work.) I have sometimes had to add "-fno-strict-aliasing -fwrapv" to deal with UB in other people's code, which always feels uncomfortable. And of course sometimes you get handed code written by a muppet with no clue what they are doing. I once had to debug code written by someone who did not see the point in keeping the number and type of parameters in sync between function definitions and function calls. The parts of the program that worked did so by sheer chance.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-06-02 15:06 +0000 |
| Subject | Microcontroller software stacks (was Re: this girl calls c ugly) |
| Message-ID | <fkCTR.17300$_BG8.7520@fx24.iad> |
| In reply to | #399616 |
cross@spitfire.i.gajendra.net (Dan Cross) writes:
>In article <10vlvie$2ne3j$2@dont-email.me>,
>David Brown <david.brown@hesbynett.no> wrote:
<snip>
>
>Yes. The way one boots an AMD server SoC, for instance,
>requires shipping a bunch of binary data structures around to
>little microcontrollers spread across a bunch of AXI buses, that
>are then responsible for things like configuring PCIe links and
>enumerating IO buses and so on. The vendor code for doing this
>is opaque, at best. For example,
>https://github.com/openSIL/openSIL/blob/turin_poc/xUSL/Nbio/Brh/NbioPcieComplexDataBrh.c
>(and that's a cleaned-up version).
Indeed, even the high-speed SERDES now have small microprocessors
that need proprietary firmware loaded at power-on.
Most vendors prefer to keep such details proprietary, for various
reasons both good and bad.
I'll agree that software (firmware) development at chip vendors
has been, in the past, an afterthought with the primary emphasis
on the hardware side. In modern chip design, software has taken
a larger role in both hardware definition, and the software
quality has improved somewhat.
>
>>[snip color mapping code]
>>
>>Yes, that would be vastly better. (I would still prefer to have
>>different named types for colours in the different encoding schemes.)
>
>I'll see your named types and raise you a bitfield struct. The
>shifting and masking is superfluous.
Or useful helpers:
a = bit::extract(value, 12, 0); /* Extract bits 12:0 from value */
b = bit::insert(b, 0x10, 5, 5); /* Insert 0x10 into b starting at bit 5 for 5 bits */
One might also define data structures for control and status registers using
bitfield structs.
e.g. for the SATA UAHC_GLB_OOBR register:
union UAHC_GBL_OOBR {
uint32_t u;
struct UAHC_GBL_OOBR_s {
#if __BYTE_ORDER == __BIG_ENDIAN
uint32_t we : 1; /**< R/W/H - Write enable. */
uint32_t cwmin : 7; /**< R/W/H - COMWAKE minimum value. Writable only if WE is set. */
uint32_t cwmax : 8; /**< R/W/H - COMWAKE maximum value. Writable only if WE is set. */
uint32_t cimin : 8; /**< R/W/H - COMINIT minimum value. Writable only if WE is set. */
uint32_t cimax : 8; /**< R/W/H - COMINIT maximum value. Writable only if WE is set. */
#else
uint32_t cimax : 8;
uint32_t cimin : 8;
uint32_t cwmax : 8;
uint32_t cwmin : 7;
uint32_t we : 1;
#endif
} s;
};
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-05-31 19:11 +0000 |
| Message-ID | <10vi15t$ovl$1@reader1.panix.com> |
| In reply to | #399538 |
In article <10vemqf$r5qe$1@dont-email.me>, Bart <bc@freeuk.com> wrote: >On 30/05/2026 13:29, Dan Cross wrote: >> In article <10vd1tu$ekvl$1@dont-email.me>, Bart <bc@freeuk.com> wrote: >>> On 29/05/2026 21:56, Keith Thompson wrote: >>>> [snip] >>>> Upthread, you asked a question: >>>> >>>> And then the point becomes, if you always add the parentheses, what >>>> was the point of having that particular precedence level? >>>> >>>> You've made it clear that you were never interested in an answer. >>> >>> You said this: >>> >>> "You're asking why C is designed the way it is. We could waste a >>> great deal of time and effort answering that for you. There are >>> numerous documents about the design and history of C, and of >>> its ancestor languages. I could provide you with links." >>> >>> Actually I'm not asking why C is like that. We're already there. >>> >>> I'm saying that there is no value in those extra levels, some people >>> think is, and I'm arging about that. I was replying to tTh. >>> >>> As for my question, what /is/ the point? I'm still waiting! >> >> To clarify: the question is, what is the point of those levels? >> >> How is that different from asking "why C is like that"? > >My question is actually independent of C or its history. > >I accept those levels exist. I was asking do they currently serve a >useful purpose. That is a distinction without a difference: I do not see how the two can be separated from one another. The useful purpose the C rules serve is allowing existing code to compile unmodified; the reason that existing code was written that way is because that's how the language was defined; the language was defined that way due to the aforementioned history. >If not, people can choose to ignore those them when writing C code, for >example like this where all () are technically superfluous: > > crcu32 = (crcu32 >> 4) ^ s_crc32[(crcu32 & 0xF) ^ (b & 0xF)]; > >And they can choose to not adopt them when devising new languages, >however many still do faithfully recreate the same pattern, with a few >notable exceptions such as Go lang. Languages should, presumably, do what makes sense for them. Lots of languages echo parts of C's syntax where that has proven to be convenient and popular; curly braces for grouping might be an example there. Others have not, or have purposely discarded parts of C syntax that have proven awkward or unpopular. An example there might be the variable declaration syntax, or the structure of `typedef`. I can't think of many languages that keep the exact same parsing rules with respect to operator precedence. You mentioned Go; neither Rust nor Zig follow C's rules, either. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-05-31 16:08 -0700 |
| Message-ID | <86ldczdvor.fsf@linuxsc.com> |
| In reply to | #399536 |
cross@spitfire.i.gajendra.net (Dan Cross) writes: > In [...] early C, `|` and `&` were logical operators. The > short-circuiting `||` and `&&` came later, but the usage low > precedence for `|` and `&` was already baked in. > > That's the point: the precedence reflects the original use as > boolean operators, not how things evolved for use almost purely > as bitwise operators. Surely even in pre-K&R C the & and | operators were used for bitwise-and and bitwise-or as well as logical connectors.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-05-31 16:32 -0700 |
| Message-ID | <10vige1$1r8io$2@kst.eternal-september.org> |
| In reply to | #399570 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> cross@spitfire.i.gajendra.net (Dan Cross) writes:
>> In [...] early C, `|` and `&` were logical operators. The
>> short-circuiting `||` and `&&` came later, but the usage low
>> precedence for `|` and `&` was already baked in.
>>
>> That's the point: the precedence reflects the original use as
>> boolean operators, not how things evolved for use almost purely
>> as bitwise operators.
>
> Surely even in pre-K&R C the & and | operators were used for
> bitwise-and and bitwise-or as well as logical connectors.
They were used for both (and that was the problem).
The "original use" being referred to is in BCPL and B, and in *very*
early C.
Reference:
https://www.nokia.com/bell-labs/about/dennis-m-ritchie/chist.pdf
Neonatal C
Rapid changes continued after the language had been named,
for example the introduction of the && and || operators. In
BCPL and B, the evaluation of expressions depends on context:
within if and other conditional statements that compare an
expression’s value with zero, these languages place a special
interpretation on the and (&) and or (|) operators. In ordinary
contexts, they operate bitwise, but in the B statement
if (e1 & e2) ...
the compiler must evaluate e1 and if it is non-zero, evaluate e2,
and if it too is non-zero, elaborate the statement dependent on
the if. The requirement descends recursively on & and | operators
within e1 and e2. The short-circuit semantics of the Boolean
operators in such ‘truth-value’ context seemed desirable,
but the overloading of the operators was difficult to explain
and use. At the suggestion of Alan Snyder, I introduced the &&
and || operators to make the mechanism more explicit.
Their tardy introduction explains an infelicity of C’s
precedence rules. In B one writes
if (a==b & c) ...
to check whether a equals b and c is non-zero; in such a
conditional expression it is better that & have lower precedence
than ==. In converting from B to C, one wants to replace & by
&& in such a statement; to make the conversion less painful,
we decided to keep the precedence of the & operator the same
relative to ==, and merely split the precedence of && slightly
from &. Today, it seems that it would have been preferable to
move the relative precedences of & and ==, and thereby simplify
a common C idiom: to test a masked value against another value,
one must write
if ((a&mask) == b) ...
where the inner parentheses are required but easily forgotten.
--
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 17:12 -0700 |
| Message-ID | <868q8zdspk.fsf@linuxsc.com> |
| In reply to | #399572 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > >> cross@spitfire.i.gajendra.net (Dan Cross) writes: >> >>> In [...] early C, `|` and `&` were logical operators. The >>> short-circuiting `||` and `&&` came later, but the usage low >>> precedence for `|` and `&` was already baked in. >>> >>> That's the point: the precedence reflects the original use as >>> boolean operators, not how things evolved for use almost purely >>> as bitwise operators. >> >> Surely even in pre-K&R C the & and | operators were used for >> bitwise-and and bitwise-or as well as logical connectors. > > They were used for both [...] That's all I was saying.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-05-30 14:07 +0200 |
| Message-ID | <10vejt6$qmam$2@dont-email.me> |
| In reply to | #399504 |
On 29/05/2026 19:53, Bart wrote: > On 29/05/2026 18:29, tTh wrote: >> On 5/29/26 15:22, Bart wrote: >> >>> Something you might do when you have time (as I'm busy), is to >>> analyse the expressions in some C codebases, and isolate those where >>> removal of parentheses that group terms, would result in exactly the >>> same shape of expressions, and are therefore redundant. >> >> This is a strange exercice. When I write complex expression, >> I sometime use redondant parenthesis for the clarity of >> my intentions about this computation. I'm thinking that >> those extra (()) are a sort of in-line comments. >> > > Sure, but some here like to say that such expressions, if they still > work without parentheses, are unambiguous anyway. They are obviously unambiguous to compilers, and they are unambiguous to people who either know the precedence rules, or are able to look them up to be sure of them at the time. For those that don't know the rules and would rather guess randomly, they might misinterpret the expressions but the expressions themselves are still unambiguous. So yes, complex expressions without parentheses /are/ unambiguous. However, being unambiguous does not mean people will not make mistakes when reading or writing them, or that they can read and write them correctly without effort. As you say, people are not compilers. Parentheses can certainly reduce the cognitive effort for people reading or writing complex expressions, and can significantly reduce the risk of errors. Extra local variables for sub-expressions can do this too (especially when the language has good scoping rules and allows variables to be declared when you need them). So it is wrong to suggest that expressions written in C without extra parentheses are somehow "ambiguous" - but it is correct to say that adding extra parentheses (within reason) can often help the readability of code. And this applies equally in all languages, no matter what precedence the operators have, or how many levels there are. I can certainly agree with you that C would have been slightly nicer if the bitwise operators and equality operators were at different precedences. There are a number of changes I would have preferred - some of which you would agree with, some not. But even if C were to have those changes overnight, it would not change anything about what I wrote above. Regardless of the operator precedence, expressions are not ambiguous, but parentheses or splitting into sub-expressions can make code clearer.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-05-29 18:10 +0200 |
| Message-ID | <10vcdpr$3uus8$3@dont-email.me> |
| In reply to | #399490 |
On 2026-05-29 13:19, Bart wrote:
> How about:
Generally; if in doubt you can always inspect the precedence
table that you find in K&R and elsewhere. Below some hints to
hopefully reduce your confusion...
>
> * What is the order here: a ^ b | c
Personally I don't think that there's a prevalent definition
how these should be ordered. - But note the history of these
operators, which was BTW why they are in "C" at the positions
that they are; their (potential) use as boolean sets.
To memorize the bit-value operations you can associate them
with the glyphs for the boolean operations; per convention
AND (&&) comes before OR (||), and insert the bitwise xor in
between. - As said; there's a rationale for the choice, and
a historic explanation (that makes sense), but you can in
case of doubt or to make things clearer also use parentheses.
>
> * Why do bitwise & | ^ need their own level anyway
For historic reasons of potential use. (As said above.)
>
> * What is most intuitive precedence here: a << 3 + b, and what
> is it in C
What it is in "C" you should look up in the precedence table.
What it is intuitively depends on what the programmer wanted to
express. As it is written a shift by a calculated expression
seems have been the intention, and that's also how "C" handles
that.
Why would one who intends to say: make space for three bits in
'a' to put there the bit-pattern stored in 'b'? If I'd wanted to
express that I'd use a binary '|', and because or the well known
precedence I'd have no parenthesis around, as in a << 3 | b .
Of course there's also the potential semantics that you have a
'b' that exceeds three bit and you want to have that added to the
shifted value of 'a'. But then I'd not use bit-value operations
to express that but the clear and more appropriate a * 8 + b .
Both semantics bit-op and int-arithmetic don't need parenthesis
in "C" because of its clear and sensible precedence.
You are mixing bit-ops and arithmetic unnecessarily, but you are
also too lazy to write parenthesis to clear up your dirty code?
>
> * Why do << >> have their own level anyway
As you have been told so many times; to not require parentheses
unnecessarily, to be able to omit them and not pollute the code
with parentheses in a language that is already full of all sorts
of { } [ ] ( ) and other punctuation characters.
>
> * Why do == != have a difference precendence from < <= >= >
I've explained that already twice in the past.
>
> Further, here: 'a * b + c' the multplication is done first, but here:
>
> a *= b += c
>
> It is done second.
You understand that '=', '*=', and '*' are three different things,
don't you?
I hope you understand that '=' should have low precedence. And that
it makes sense to evaluate that from right to left. Do you follow?
"C" obviously decided to have them all, =, +=, *=, etc. in a single
group, and thus evaluated from right to left. - Easy rule, easy to
memorize. - And that is actually what you are demanding from many
other operators, to put them in a single group. - But here you are
complaining about it!
Of course the rules for those combined (sort of two-address) operators
could have been defined differently, in an own group with other rules.
(Algol 68 had done that, actually; the semantics are like "apply these
operations from left to right, indicating an incremental modification
of the underlying value.)
If "C" would have separated these operators from the assignment and
created another own group with different evaluation rules you'd also
have complained.
>
> The issue I have is whether augmented assignments should return a value
> at all. It's just generally too confusing especially with mixed types.
If you're confused about something either try to understand the rule,
or just learn it without understanding it, or look it up, a or write
your programs in a way that you understand; use parentheses, separate
complex expressions to simpler ones, etc.
> It's confusing enough with assignments returning a value:
>
> a = b = x;
If it hurts/confuses you then don't use that feature.
>
> Here, assuming x has no side-effects, you might expect this to mean the
> same as:
>
> b = x;
> a = x;
I cannot tell what your brain makes you expect one semantic or another.
The semantics are clearly defined. Your interpretation here is wrong.
All I can suggest is what I've written above already; and to spare you
a search, it was:
If you're confused about something either try to understand the rule,
or just learn it without understanding it, or look it up, a or write
your programs in a way that you understand; use parentheses, separate
complex expressions to simpler ones, etc.
>
> In fact it's more like: 'b = x; a = b;'. Example:
>
> double a;
> float b;
>
> a = b = 3.14159265358979323846;
>
> Here, 'a' will be assigned the less precise 32-bit version of the RHS.
And why are you composing such stupid examples (if not only for sake
of an argument)? - An experienced programmer wouldn't write such an
expression with mixed types if he intends clear and non-dubious code.
Janis
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-05-29 19:18 +0100 |
| Message-ID | <10vcl99$aquo$3@dont-email.me> |
| In reply to | #399499 |
On 29/05/2026 17:10, Janis Papanagnou wrote:
> On 2026-05-29 13:19, Bart wrote:
>> Further, here: 'a * b + c' the multplication is done first, but here:
>>
>> a *= b += c
>>
>> It is done second.
>
> You understand that '=', '*=', and '*' are three different things,
> don't you?
>
> I hope you understand that '=' should have low precedence. And that
> it makes sense to evaluate that from right to left. Do you follow?
>
> "C" obviously decided to have them all, =, +=, *=, etc. in a single
> group, and thus evaluated from right to left. - Easy rule, easy to
> memorize. - And that is actually what you are demanding from many
> other operators, to put them in a single group. - But here you are
> complaining about it!
>
> Of course the rules for those combined (sort of two-address) operators
> could have been defined differently, in an own group with other rules.
> (Algol 68 had done that, actually; the semantics are like "apply these
> operations from left to right, indicating an incremental modification
> of the underlying value.)
For those who don't know, the behaviour of this C code:
a += b += c += d
is very different from the equivalent Algol68:
a +:= b +:= c +:= d
This only modifies 'a'.
>> In fact it's more like: 'b = x; a = b;'. Example:
>>
>> double a;
>> float b;
>>
>> a = b = 3.14159265358979323846;
>>
>> Here, 'a' will be assigned the less precise 32-bit version of the RHS.
>
> And why are you composing such stupid examples (if not only for sake
> of an argument)? - An experienced programmer wouldn't write such an
> expression with mixed types if he intends clear and non-dubious code.
Maybe the code started off as:
a = x;
b = x;
and somebody decided to refactor it. Or it was 'a = b = x' all along but
a, b started off as the same type but then one was changed.
These things happen. When discussing language design we have to consider
what thousands or millions of programmers might think or assume.
You seem to like making it 100% about me. How about stopping making it
always so personal.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-05-29 22:17 +0200 |
| Message-ID | <10vcs9i$3uus7$6@dont-email.me> |
| In reply to | #399507 |
On 2026-05-29 20:18, Bart wrote: > On 29/05/2026 17:10, Janis Papanagnou wrote: >> On 2026-05-29 13:19, Bart wrote: > >>> Further, here: 'a * b + c' the multplication is done first, but here: >>> >>> a *= b += c >>> >>> It is done second. >> >> You understand that '=', '*=', and '*' are three different things, >> don't you? >> >> I hope you understand that '=' should have low precedence. And that >> it makes sense to evaluate that from right to left. Do you follow? >> >> "C" obviously decided to have them all, =, +=, *=, etc. in a single >> group, and thus evaluated from right to left. - Easy rule, easy to >> memorize. - And that is actually what you are demanding from many >> other operators, to put them in a single group. - But here you are >> complaining about it! >> >> Of course the rules for those combined (sort of two-address) operators >> could have been defined differently, in an own group with other rules. >> (Algol 68 had done that, actually; the semantics are like "apply these >> operations from left to right, indicating an incremental modification >> of the underlying value.) > > For those who don't know, the behaviour of this C code: Those you have read my post already know that, since that was what I explained as a possible alternative rule for these sorts of operators. (It's still quoted above.) Folks here are capable of understanding that without your echoing post. > > a += b += c += d > > is very different from the equivalent Algol68: > > a +:= b +:= c +:= d > > This only modifies 'a'. I explained already in my post that there's a difference. (Are you so proud of having understood that that you want to repeat it? - "Look Ma, no hands!") (And neither is "perfect"; both are sensible choices. - Not sure you understand that.) > [...] > > You seem to like making it 100% about me. How about stopping making it > always so personal. What you expose here (about your personality) is nothing new, and it's about your personality; you obviously aren't really interested to know or understand or learn the facts. You had asked, even insisted for answers to your samples because you obviously weren't intellectually capable of understanding the topic, and all you posted is this reply! - Pathetic! Janis
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-05-29 21:47 +0100 |
| Message-ID | <10vcu1a$dhga$1@dont-email.me> |
| In reply to | #399515 |
On 29/05/2026 21:17, Janis Papanagnou wrote: > On 2026-05-29 20:18, Bart wrote: > (Are you > so proud of having understood that that you want to repeat it? - > "Look Ma, no hands!") > What you expose here (about your personality) is nothing new, and > it's about your personality; you obviously aren't really interested > to know or understand or learn the facts. > you obviously weren't intellectually capable of understanding the > topic, and all you posted is this reply! > - Pathetic! It doesn't look like a civil discussion is possible here, so long as you keep up the personal insults. I thank you for those replies but there doesn't seem any point in taking this further.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2026-05-29 15:57 -0400 |
| Message-ID | <10vcr2j$cnak$1@dont-email.me> |
| In reply to | #399499 |
On 2026-05-29 12:10, Janis Papanagnou wrote: > On 2026-05-29 13:19, Bart wrote: ... >> * What is the order here: a ^ b | c (a^b)|c > Personally I don't think that there's a prevalent definition > how these should be ordered. I'm not sure what you mean by "prevalent definition". Ordinarily, I'd expect the C standard to qualify - it definitely defines the order, and the very purpose of a language standard is to prevail over non-standard alternatives. However, I'm sure you're aware of the C standard, and made that comment anyway, so I presume you mean something different by it.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-05-29 22:34 +0200 |
| Message-ID | <10vct80$3uus8$7@dont-email.me> |
| In reply to | #399511 |
On 2026-05-29 21:57, James Kuyper wrote:
> On 2026-05-29 12:10, Janis Papanagnou wrote:
>> On 2026-05-29 13:19, Bart wrote:
> ...
>>> * What is the order here: a ^ b | c
>
> (a^b)|c
>
>> Personally I don't think that there's a prevalent definition
>> how these should be ordered.
>
> I'm not sure what you mean by "prevalent definition". Ordinarily, I'd
> expect the C standard to qualify - it definitely defines the order, and
> the very purpose of a language standard is to prevail over non-standard
> alternatives. However, I'm sure you're aware of the C standard, and made
> that comment anyway, so I presume you mean something different by it.
It was about Bart's confusion; he seems to be looking for something
"naturally" understandable, like the common * and / have precedence
over + and - , which is known by most non-IT people from basic math.
There is no such commonly know ("prevalent") definition for the bit
operations. So we need to look that up in appropriate documents to
get to know their evaluation order. - That was what I intended to
express.
Sorry if that was unclear, and thanks for asking to clarify that.
How "C" defines their precedence can of course be read in any book
about "C", there's not even a "C Standard" document necessary.
In addition I gave an explanation why they decided to have these
operators in three separated precedence groups, and hinted on what
was the rationale for the same order as the boolean && and || .
Janis
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-05-29 23:18 +0000 |
| Message-ID | <10vd6si$g0t9$1@dont-email.me> |
| In reply to | #399490 |
On Fri, 29 May 2026 12:19:04 +0100, Bart wrote: > * Why do bitwise & | ^ need their own level anyway So that you can do shifting and masking with minimal parentheses. > * Why do << >> have their own level anyway So that shift expressions can use common arithmetic operators with minimal parentheses. > Further, here: 'a * b + c' the multplication is done first, but > here: > > a *= b += c > > It is done second. That kind of thing is disallowed in Python, for some reason.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-05-30 01:26 +0100 |
| Message-ID | <10vdas7$gtcd$1@dont-email.me> |
| In reply to | #399522 |
On 30/05/2026 00:18, Lawrence D’Oliveiro wrote: > On Fri, 29 May 2026 12:19:04 +0100, Bart wrote: > >> * Why do bitwise & | ^ need their own level anyway > > So that you can do shifting and masking with minimal parentheses. Can you give examples? Because you can do 'a << b & c' without << >> needing their own private level; it only needs to be lower than bitwise ops. For example they could have the same level as * and / as they essentially do the same thing. >> * Why do << >> have their own level anyway > > So that shift expressions can use common arithmetic operators with > minimal parentheses. Again, examples? > >> Further, here: 'a * b + c' the multplication is done first, but >> here: >> >> a *= b += c >> >> It is done second. > > That kind of thing is disallowed in Python, for some reason. I disallow it too (in my stuff). It's too confusing, no matter that is 100% unambiguous according to some arcane language rules.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-05-30 04:25 +0000 |
| Message-ID | <10vdorr$jvkg$1@dont-email.me> |
| In reply to | #399524 |
On Sat, 30 May 2026 01:26:47 +0100, Bart wrote:
> On 30/05/2026 00:18, Lawrence D’Oliveiro wrote:
>>
>> On Fri, 29 May 2026 12:19:04 +0100, Bart wrote:
>>
>>> * Why do bitwise & | ^ need their own level anyway
>>
>> So that you can do shifting and masking with minimal parentheses.
>
> Can you give examples?
You haven’t done much bit manipulation, have you?
Extracting RGB components from a pixel:
const unsigned int
r = pixel >> 16 & 255,
g = pixel >> 8 & 255,
b = pixel & 255;
Combining RGBA components into a pixel:
colors[i] =
channel[0] << 24
|
channel[1] << 16
|
channel[2] << 8
|
channel[3];
>>> * Why do << >> have their own level anyway
>>
>> So that shift expressions can use common arithmetic operators with
>> minimal parentheses.
>
> Again, examples?
From the same code module, putting together a subpicture image
consisting of 2 bits per pixel:
pixbuf[bufpixels / 4] |= histogram[histindex].index << bufpixels % 4 * 2;
<https://bitbucket.org/ldo17/dvd_menu_animator/src/master/spuhelper.c>
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-05-30 12:01 +0100 |
| Message-ID | <10veg28$ps93$1@dont-email.me> |
| In reply to | #399529 |
On 30/05/2026 05:25, Lawrence D’Oliveiro wrote:
> On Sat, 30 May 2026 01:26:47 +0100, Bart wrote:
>
>> On 30/05/2026 00:18, Lawrence D’Oliveiro wrote:
>>>
>>> On Fri, 29 May 2026 12:19:04 +0100, Bart wrote:
>>>
>>>> * Why do bitwise & | ^ need their own level anyway
>>>
>>> So that you can do shifting and masking with minimal parentheses.
>>
>> Can you give examples?
>
> You haven’t done much bit manipulation, have you?
>
> Extracting RGB components from a pixel:
>
> const unsigned int
> r = pixel >> 16 & 255,
> g = pixel >> 8 & 255,
> b = pixel & 255;
This merely requires <<'s precendence to be lower than &.
It doesn't need & | ^ to be distinct (only one is used here anyway).
It doesn't beed << >> to be in a distinct group from multiply or add groups.
> Combining RGBA components into a pixel:
>
> colors[i] =
> channel[0] << 24
> |
> channel[1] << 16
> |
> channel[2] << 8
> |
> channel[3];
Exactly the same applies here. But if one of those | was & or ^, then
you might start needing parentheses.
>>>> * Why do << >> have their own level anyway
>>>
>>> So that shift expressions can use common arithmetic operators with
>>> minimal parentheses.
>>
>> Again, examples?
>
> From the same code module, putting together a subpicture image
> consisting of 2 bits per pixel:
>
pixbuf[bufpixels / 4] |= histogram[histindex].index << bufpixels
% 4 * 2;
This is a better example, as is this from your link:
pixbuf[nr_buf_pixels] = colors[srcpix >> src_pix_index * 2 & 3];
This can indeed be written with fewer parentheses given the priority of
<< relative to * and &.
But it is also not clear because the part after >> is sprawling. You'd
want it like this:
pixbuf[nr_buf_pixels] = colors[srcpix >> (src_pix_index * 2) & 3];
Now there is less analysis to do to establish the span of the shift-count.
These are examples from MZLIB:
crcu32 = (crcu32 >> 4) ^ s_crc32[(crcu32 & 0xF) ^ (b & 0xF)];
crcu32 = (crcu32 >> 4) ^ s_crc32[(crcu32 & 0xF) ^ (b >> 4)];
C's precedence rules say that many of those parentheses are not strictly
needed, which means the following are exactly equivalent:
crcu32 = crcu32 >> 4 ^ s_crc32[crcu32 & 0xF ^ b & 0xF];
crcu32 = crcu32 >> 4 ^ s_crc32[crcu32 & 0xF ^ b >> 4];
So why were they added? Could it be that they make things clearer?
Remove ambiguity in the mind of the reader? Leader to fewer surprises
when a new term needs to be added?
With the original, NOBODY NEEDS TO CARE what the hell the precedences of
>> ^ & with respect to each other. Port the fragment to a language with
slightly different rules and it it would still work.
Post that fragment somewhere, and people will know what it means
*without needing to know which exact language it is*.
This is why I think it is pointless to devote 4 dedicated levels to <<
>> & | ^, and poor to rely on them for the meaning of your code.
[toc] | [prev] | [next] | [standalone]
Page 8 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