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.


--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 2026-05-29 20:09, Bart wrote:

You actually said this:

You continue your trollish stance to cherry-pick words without
understanding or trying to understand what's been expressed.

The insight appears to me that you're taking communication in a
similar way as you "design" your languages; focusing on personal
*syntax* preferences instead of the more important *semantics*.

Despite we're talking in your native language (and not mine) you
obvious completely miss or deliberately ignore that there's a
difference between "it makes perfectly sense" and "it's perfect".
(I said the former, you put the latter in my mouth. And to not
get identified as a liar you're squirming with such moves. Gee!)

Or are again just confused about the difference, and despite you
have already been advised to quote what I think can neither be
misrepresented nor misinterpreted (since it doesn't contain common
word patterns that obviously confuse you)
>> What I would say is that operator precedences are in "C"
>> "sensibly and appropriately defined, modulo the bit-ops".
you're still playing your stupid game; you ignored that. I suggest
to try to map this statement to either of the above two statements,
the one I said and the one you (wrongly) attributed, and see which
one fits. (Hint: the former.)

[...]

Dan Cross:

Programmers _should_ absolutely learn the rules.ÿ But in C,
there are many of them, and some of them are deceptively subtle.

JP:

We agreed.

Bart, you are incapable of understanding semantics and associating
context.

Janis


--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 2026-05-29 21:49, Bart wrote:

On 29/05/2026 20:28, Keith Thompson wrote:

Bart <bc@freeuk.com> writes:

or would you continue to post contrived examples that make it appear
as confusing as possible?

Examples are examples. Do you want me to post one that didn't illustrate
an issue? It necessaily has to be contrived.

Bart, what do you want?

Today I was just replying to this post today that I found annoying:

JP:

Unsurprisingly; since exactly *that* was the obvious (and single)
issue with C's precedence definitions.

That is, the suggestion, made several times by JP, that there is only
one thing wrong.

The C-precedence rules have one issue. The rest is a sensible choice.

(The C-language has more issue, but that was not the topic here.)

Janis


--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 5/29/2026 6:22 AM, David Brown wrote:

On 29/05/2026 12:20, BGB wrote:

On 5/29/2026 2:52 AM, Janis Papanagnou wrote:

On 2026-05-28 11:57, BGB wrote:

On 5/28/2026 2:18 AM, Janis Papanagnou wrote:

On 2026-05-28 01:49, BGB wrote:

[...]

But, not really an "easy" way to avoid bloat, other than to write
code specifically for what cases are relevant; while also avoiding
needless duplication and copy paste (where, overuse of copy/paste
can also lead to bloat; along with turning the code into an ugly mess). >>>

Hmm.. - as said, the during very early days there were issues; I
recall on one platform duplication of template code in more that
one source unit. And/or some environmental hacks (of the compiler)
to deposit template code for linking. In the later days I've not
seen such immature things anymore.

Possibly, a lot could depend on how one is counting things as well.


In a lot of cases when using GCC, I end up using:
ÿÿ -ffunction-sections -fdata-sections -Wl,-gc-sections

On many targets, "-fdata-sections" can lead to noticeably larger and
slower code because it effectively eliminates section anchor
optimisations.ÿ It does not negatively affect x86 AFAICS, because x86
does not use section anchors.

<https://godbolt.org/z/zeoq41Y7d>

With -fsection-anchors (enabled with optimisation on targets that
support it - generally RISCy load/store architectures), program-lifetime variables are kept together in a lump (as though they were in a struct)
and often addressed by a pointer to that pretend struct.ÿ Thus if a
function accesses two variables "a" and "b", instead of having to load
the addresses of each of "a" and "b" into separate registers, it loads
an "anchor" into one register and accesses the variables with reg+offset addressing.

I've seen "-fdata-sections" used regularly in embedded systems - it is almost always a bad idea.

("-ffunction-sections" is often very helpful to reduce code image size,
so keep that one.)

Both seem to help on x86, x86-64, and also on RISC-V, at making GCC's
output at least sorta space-comparable to my own compilers.

The merit of "-fdata-sections" is mostly that it eliminates unused
global variables; whereas "-ffunction-sections" eliminates unreachable functions.

Neither is needed with my own compiler, which compiles things in a way
such that it eliminates anything that is unreachable.


Both posed an issue initially when porting ROTT, because in some cases
it relied on the ability to go out-of-bounds for one array to access
data in another array. I ended up reworking some of these cases though
to use a single larger array.



Have noted though that GCC targeting RISC-V still tends to produce
fairly large binaries even with "-Os". Its code for the basic subset
(RV64G) does tend to be a little faster than what BGBCC generates, but
also a fair bit more bulky. Though, the final ELF file ends up bigger
still, as a significant chunk of the file ends up needing to hold ELF
related metadata (comparably, PE/COFF can end up much leaner here).


Though, on the other side, with modern MSVC, despite the relative
leanness of the PE/COFF format, MSVC tends to produce binaries with much larger ".text" sections.

This issue was a lot less with VS2008 though, which tended to generate less-bloated binaries (with code-size more competitive with GCC).


Also in modern MSVC, there is little distinction between "/O1" and
"/Os", both being more space-efficient than "/O2" (though, "/O2" is
usually faster, but also more prone to misguided attempts at auto-vectorization).

Because otherwise it likes wasting code space by retaining unreachable
functions.

Using "static inline" functions also carries a risk because the can
end up duplicated across multiple translation units, or in multiple
places within the same translation unit, so is best used sparingly.

Usually you would only use static inline functions for small functions
in headers, where they are a better choice than function-like macros. In
a C file, there is rarely much point in declaring a function "inline" - optimising compilers will inline or not as they see fit, without regard
for "inline".ÿ "static" on its own is, of course, always a good idea for functions or data that is not "exported" by the current translation
unit, and will often make generated code smaller.

How much or how little duplication of code there will be within one translation unit will depend on compiler settings and the rest of the
code, and not on whether or not you use "inline".

OK.

But, yeah, small functions are usually better than macros in at least
that the compiler can avoid duplicating them (or maybe merge them
between translation units when it notices that the contents are identical).

As for assembler:
Main reasons not to use assembler for everything:
ÿÿ Needlessly verbose;
ÿÿ Non-portable.

However, often one can still end up writing C code that looks like
assembler sometimes, as this is often an effective way to optimize
things.

Say, for example:
ÿÿ v0=cs[0];
ÿÿ v2=cs[2];
ÿÿ v1=cs[1];
ÿÿ v3=vs[3];
ÿÿ ct[0]=v0;
ÿÿ ct[2]=v2;
ÿÿ ct[1]=v1;
ÿÿ ct[3]=v3;
Vs:
ÿÿ ct[0]=cs[0];
ÿÿ ct[1]=cs[1];
ÿÿ ct[2]=cs[2];
ÿÿ ct[3]=cs[3];

Because the extra variables can avoid help sidestep latency from the
load instructions and staggering stores can avoid penalties of two
adjacent stores to the same cache-line in some cache architectures.
Where, in the latter case, the compiler may fail to as effectively
avoid the load-latency or realize the need to stagger the stores for
best performance, ...

That might be the case for a very simplistic compiler.ÿ With an
optimising compiler, these extra variables will quickly be eliminated.
If the compiler has a good scheduling model of the device, it do
whatever instruction scheduling works best for that processor.ÿ If the
model is not good enough, it will be suboptimal.ÿ I would not, however, expect any different in the generated code for the two code snippets.

Sometimes this kind of "manual optimisation" is helpful when you have to
try to get efficient results from a weak compiler, however.

Possibly, but this sort of thing can help with both BGBCC and with MSVC IME.


While BGBCC does use a shuffle-to-reorder instructions things, it may
fail to do so in some cases:
If the instructions end up mapped to the same CPU register;
If its heuristics can't prove non-alias.

Though, in the simple example given, it could (probably) turn the latter
into the former, but "better" to write code such that things are in
closer to the optimal order by default.

Note that using different variables with overlapping scopes reduces the likelihood of the compiler assigning both to the same register, which is
a much more real risk if relying on implicit temporaries (whose lifetime
only exists within a single expression).

But, in my case, a lot of this comes down to trying to tweak the
compilers' internal register allocation heuristics for best results (and
the tight balance between how many registers to save/restore for the
function, vs avoiding assigning short-lived temporaries to the same
register too quickly and hindering the instruction-scheduling).

Arguably, could make sense to instead do the reordering at the 3AC
level, rather than reordering at the level of ISA instructions, but this
is just sorta how I ended up doing things (and one can know the
effective timing latency of a CPU instruction a lot more easily than a
3AC op).

Usual strategy is to try to limit how much code is written, and also
to avoid doing things in ways that result in too much code, or too
much cruft.

Best to avoid both copy paste when reasonable, and sticking anything
non-trivial in macros.

We avoided macros if possible.

They are de-facto for constants and similar, but for longer stuff is
better avoided.

Macros are rarely the best way to define constants.ÿ They are needed if
you are using the constants for pre-processor stuff like conditional compilation.ÿ But generally you get clearer code, better typing, and potentially several other benefits from using alternative choices like "enum" (even for stand-alone integer constants), "static const"
variables, and in C23, "constexpr" variables.ÿ There's no doubt that a
lot of code /does/ use macros for constants, but I view it as a relic of
the past rather than good coding practice.

They are traditional...

Like:
static const double M_PI = 3.14159265358979;

Could also make sense, but people don't do usually this, they usually
use macros...

In BGBCC, both can be handled as constants, just they end up being
handled at different stages:
#define: Constant ends up inlined in the preprocessor/parse stage;
const: Constant shows up in the "reducer" (which evaluates constant expressions).

Where, as noted, BGBCC's pipeline looks kinda like:
Toplevel:
Ingest each named source file;

Then, in the C case, per translation unit:
Preprocess;
Parse;
Frontend Compile + Reduce;
This does an AST walk, but at each stage,
invokes the reducer to see if it can perform AST level rewrites;
Reducer can also implement some edge-case features.
So, is mostly necessary, vs an optional optimization thing.
Emits output as a Stack IL.
May be output to a file, or used as input to next stage.
The stack IL partly resembles a mix of JVM and .NET bytecode.
The IL ops themselves operate more like in .NET bytecode.
This serves the role of static libraries and object files.
For a static library, all the stack IL gets blobbed together.
So, every translation unit ends up effectively appended on.

Middle Stage (processes IL Blobs):
Processes Stack IL, translates to 3AC (loosely SSA form);
Builds a big table of all global declarations, etc.

Backend:
Walks call-graph to determine dependencies;
Unreachable functions/globals/etc are marked as culled.
Ranks all the functions and variables by priority;
Sorts them into roughly priority order;
Then does shuffling to try to density-optimize globals;
Swaps globals when doing so would allow more memory density.
May also apply random shuffling and clustering heuristics.
Then, compiles each function:
Figure out stack-frame layout,
how many registers to reserve,
etc.
Emit machine code for 3AC ops;
Try to shuffle instructions to improve instruction scheduling;
Or, if a variable:
Figure out whether it goes in ".data" or ".bss"
If initialized, deal with initialization stuff;
...
Or, an ASM Blob:
Assemble it.
Or, Ingests contents that go into ".rsrc" section;
May involve image and audio converters, etc;
BGBCC uses different resource sections from Windows though.
...
Output:
Gets is input as a set of sections, symbols, and relocs;
Figures out layout within the output image (eg, PE/COFF);
Figures out how much space it needs for base relocs, etc.
Builds up a table of "initial base-relocs"
Splats the sections into the image buffer;
Applies relevant relocs;
Sorts base relocs by RVA;
Generates actual ".reloc" section contents.
Fill in PE/COFF headers and similar;
If applicable, LZ4 compress the image.
I tend to store EXE's in LZ4 compressed form,
the image is decompressed during load.
This format leaves the initial PE/COFF headers uncompressed.
Need the headers to figure out where to load the image.
Else would need a temporary buffer to decompress into.


Typical loader process:
Look at headers;
Figure out where to load to, etc;
Read in (or decompress) image contents;
Apply base relocs;
Pull in any DLLs, etc;
Go.

The LZ4 compression is mostly because:
Loader is often IO bound;
May save memory in some cases;
LZ4 decompression is faster than more IO;
It also seems to be effective against program binaries (*).

*: I have my RP2 format, which generally does better for general purpose
data compression, but slightly worse for compressing program binaries,
so LZ4 has mostly won here. Also generally don't want a "stronger"
compressor, like Deflate, both because an Inflater is a much bigger
chunk of code, and also much slower than LZ4.



Can note that BGBCC also mostly takes over the role of the "resource
compiler" as well, so can process resources. These are generally listed
as a text file of entries to import, giving an internal "lumpname",
external filename, and a tag to specify which file conversions to apply.

I am using a vert different resource section type than Windows though,
in that I just sorta replaced it with a modified version of the Quake
WAD2 format (not to be confused with PAK, where PAK serves a different
role). Note that the WAD2 directory in this case uses RVA's and not
WAD-file offsets (so, effectively, it is integrated into the PE/COFF
image, not just a WAD file that was shoved in).

Generally, one can access lumps from C land with declarations like:
extern unsigned char __rsrc_lumpname[];


Typically, formats used internally are things like BMP and WAV. Though,
when using BMP, it is typically 16 color or 256 color to avoid wasting
space. Sometimes monochrome or 4 color. One downside of BMP is that for
a full 256-color palette it needs 1K of memory just for the palette,
tempting to consider a non-standard variant that uses RGB555 for the
palette (thus reducing it to 512 bytes). For small images it is often
smaller to store them as 16-bit hi-color to avoid the space penalty of
the color palette.

There are already non-standard BMP variants though, like BMP with LZ compression. A lot depends on what is needed for a particular use-case.


For WAV typical formats are 2 or 4 bit ADPCM at 8/11/16 kHz.
2 bit ADPCM: 16/22/32 kbps.
4 bit ADPCM: 32/44/64 kbps.

Have found encoder-side tricks to make ADPCM more compressible with LZ4. Basically, it tries to do a reverse LZ search when encoding and encodes
audio following patterns when the pattern would be a "close enough" match.

had also experimented before with using some trickery involving FIR
filters and lookup tables to improve perceptual quality of 8kHz/2b ADPCM
to try to make it sound "less like total crap". But, this requires
additional metadata and a more complex process to decode (and to get
best results with this will result in worse audio quality if the audio
is just naively decoded as 8kHz/2b ADPCM without the filters).

But, yeah, with these tricks can reduce the effective bitrate (when LZ4 compressed) down to around 8-12 kbps. Note that while entropy coding
could help more, it is modest, and the most effective strategy (range
coding) being mostly too slow to be worthwhile.

Also, of the things I have tested, ADPCM was still the front runner for "actually passable" audio quality in this domain (to me, some of the
modern cellphone codecs sound like unintelligible broken garbage, and
require much more complex decoders, not worth the bother).


only thing I have found that gets much lower bitrate is, say:
One divides the audio up into chunks of 64 samples (1/125 second for 8kHz); Pick the top 4 square-waves from between 1 and 4 kHz;
Encode the phase and intensity of each square wave.

Typically, the strategy was to break it into 4 half-octaves and pick the highest peak in each half-octave; and then totally ignore everything
below 1kHz. If the frequency and amplitude are encoded in around 16 bits
each, this achieves an effective bitrate of 8 kbps.

Though, another strategy was 8 quarter octaves and pick the top 4 loudest.

But, audio quality is worse than 2b ADPCM.

Can push it to 4kbps by only encoding the top 2 waveforms.
But, then speech sounds robotic and borderline unintelligible.
Note that dropping to 62.5 Hz sampling also makes speech unintelligible.

While traditionally, this used sine-waves (sinewave synthesis) I had
better results with square waves (simpler/cheaper, also better results audio-wise). Computational cost for decoding is fairly modest (mostly
some "for()" loops and fixed-point arithmetic).

Though, effective bitrate may be lower, because it seems that speech
encoded this way is often LZ compressible as well (and can be helped
along with pattern matching tricks).

...


But, yeah, generally want images and audio to be fairly compact when
shoving them inside an EXE or DLL, for more general asset data,
generally better to use an external file.

I had often used a custom "WAD4" format here, which is kinda like "WAD2
but with longer names and a directory tree". It then exists as a lower
cost option to the ZIP format (while semi-popular, ZIP is a
high-overhead format to be used this way).

Also can use WAD4 as a sort of VFS packaging.

But, things can be considered in relative terms:
Like, C++ may carry various penalties vs C.

I don't find C++ carries noticeably penalties compared to C, for my
embedded work.ÿ But I do disable exceptions and RTTI - exceptions may
have very little run-time time overhead, but the unwind tables can be significant when code size is important in small systems.

Yes, that is the main thing.
They carry zero performance penalty in practice;
But, have a non-zero penalty for image size.

Not enough to be a deal-breaker towards using them if they are used, but enough that one wants them disabled if not used...



--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

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


--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

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


--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

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.

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Bart <bc@freeuk.com> writes:

On 29/05/2026 20:28, Keith Thompson wrote:

Bart <bc@freeuk.com> writes:
or would you continue to post contrived examples that make it appear
as confusing as possible?

Examples are examples. Do you want me to post one that didn't
illustrate an issue? It necessaily has to be contrived.

Bart, what do you want?

Today I was just replying to this post today that I found annoying:

JP:

Unsurprisingly; since exactly *that* was the obvious (and single)
issue with C's precedence definitions.

That is, the suggestion, made several times by JP, that there is only
one thing wrong.

I note your refusal to address most of what I wrote.

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.

Please do not waste everyone's time by asking questions when you're
not interested in the answers. Please do not assume that anyone
can tell whether one of your questions is sincere, figurative,
or rhetorical.

Bart, what do you want?

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 29/05/2026 21:00, Janis Papanagnou wrote:

On 2026-05-29 20:09, Bart wrote:

You actually said this:

You continue your trollish stance to cherry-pick words without
understanding or trying to understand what's been expressed.

The insight appears to me that you're taking communication in a
similar way as you "design" your languages; focusing on personal
*syntax* preferences instead of the more important *semantics*.

Despite we're talking in your native language

English is my second language, technically.

(and not mine) you
obvious completely miss or deliberately ignore that there's a
difference between "it makes perfectly sense" and "it's perfect".
(I said the former, you put the latter in my mouth.

It's paraphrasing. Here is your quote again:

(The point is that - with the exception of & ^ | - the ranking
makes perfect[ly] sense and should be easily usable without doubt
by a concept-knowing programmer."

I've isolated the 'ly' as that is incorrect grammar and have ignored it.

I don't know what impression someone can take from this other than you
think it's all dandy apart from that one exception.

So, what am I missing? Did you mean the rest is all fine, considering
this is C, but it is not perfect?

In that case, what /would/ be perfect in your view? Assume a fantasy
language where anything is possible.

ÿ >> What I would say is that operator precedences are in "C"
ÿ >> "sensibly and appropriately defined, modulo the bit-ops".
you're still playing your stupid game; you ignored that. I suggest
to try to map this statement to either of the above two statements,
the one I said and the one you (wrongly) attributed, and see which
one fits. (Hint: the former.)

OK, so why don't you list all the things you think are amiss with C
operator precedences. Apart from that exception.



--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 29/05/2026 21:56, Keith Thompson wrote:

Bart <bc@freeuk.com> writes:

On 29/05/2026 20:28, Keith Thompson wrote:

Bart <bc@freeuk.com> writes:
or would you continue to post contrived examples that make it appear
as confusing as possible?

Examples are examples. Do you want me to post one that didn't
illustrate an issue? It necessaily has to be contrived.

Bart, what do you want?

Today I was just replying to this post today that I found annoying:

JP:

Unsurprisingly; since exactly *that* was the obvious (and single)
issue with C's precedence definitions.

That is, the suggestion, made several times by JP, that there is only
one thing wrong.

I note your refusal to address most of what I wrote.

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!

Of course, I want the answer to be that there isn't any point if
parentheses will be used anyway.

Bart, what do you want?

What answer do you want from me? As I said it was a reply to JP. You
didn't need to step it.



--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Bart <bc@freeuk.com> writes:

On 29/05/2026 21:56, Keith Thompson wrote:

[...]

I note your refusal to address most of what I wrote.

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.

Then your question was unclear. The only reasonable interpretation
I could see for your question, quoted above, is that you wanted
to know why Dennis Ritchie chose the specific precedence rules
that he chose when he was designing the C language in the 1970s.
(The precedence rules have been stable since then.)

What did you mean to ask? Was your question meant to be rhetorical?
Did you just mean to let us know that you don't like C's precedence
rules? I think we all knew that.

[...]

As for my question, what /is/ the point? I'm still waiting!

I see that (what *is* the point) as a different question from what
you wrote earlier (what *was* the point).

The rules are what they are.

I honestly don't have any strong opinions about what the rules
*should* be.

Of course, I want the answer to be that there isn't any point if
parentheses will be used anyway.

Parentheses are not always used. Some programmers know the
precedence rules well enough, and expect their readers to know them
well enough, that they don't need to add parentheses. I don't bother
with parentheses in `a = b + c` or `a + b * c`. Others might not
bother with parentheses in more obscure cases where I would use them.

C compilers must implement the rules as specified in the standard.
Future editions of the standard are unlikely to reorder the
precedence rules, since that would quietly break existing code.

C programmers may or may not choose to remember and/or take advantage
of all the precedence rules. I haven't memorized all of them myself.

[snip]

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

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.

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Fri, 29 May 2026 08:09:53 +0200, Bonita Montero wrote:

There's no language where the users are so detail focussed and open
to new features [than C++].

But they still don?t have ?try-finally?.

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

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.

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 2026-05-29 18:52, Keith Thompson wrote:

Bart <bc@freeuk.com> writes:

...

Of course, I want the answer to be that there isn't any point if
parentheses will be used anyway.

The answer, of course, is that the condition of your "if" clause is not
true. In the overwhelming majority of the cases, people do not use
parentheses to clarify the order of evaluation that is guaranteed by C's grammar rules. They only use them in the cases where they feel that
there's a significant chance of confusion. Of course, that depends upon
your audience. If I was required to write code in such a way that you
would have trouble misunderstanding it, I'd write

a = m*x + b;

as

a = ((m*x)+b);

I internalized C's grammar rules a long time ago (which causes problems
on the rare occasions when they've changed them). The main exception are
the bit-wise operators which are well known as having the wrong
precedence - but I've seldom needed to use those operators.
As a result, I seldom have any confusion as to the order of evaluation,
which makes it very hard for me to realize that it might be a good idea
to put in some redundant parentheses to clarify that order for other
people. That means that some of my code is probably more cryptic than it
should be.

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 30/05/2026 01:31, James Kuyper wrote:

On 2026-05-29 18:52, Keith Thompson wrote:

Bart <bc@freeuk.com> writes:

...

Of course, I want the answer to be that there isn't any point if
parentheses will be used anyway.

The answer, of course, is that the condition of your "if" clause is not
true. In the overwhelming majority of the cases, people do not use parentheses to clarify the order of evaluation that is guaranteed by C's grammar rules. They only use them in the cases where they feel that
there's a significant chance of confusion.

Those are the cases we're talking about! That is:

<< >> & | ^

Maybe add == != and < <= >= > is someone wants to take advantage of
their different levels, but I guess 99% wouldn't even know about what.

Most of the rest, there tends to be agreement across languages:

school arithmetic group - comparisons - logical and/or

I haven't included ?: as that's too weird.

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Bart <bc@freeuk.com> writes:

On 30/05/2026 01:31, James Kuyper wrote:

On 2026-05-29 18:52, Keith Thompson wrote:

Bart <bc@freeuk.com> writes:

...

Of course, I want the answer to be that there isn't any point if
parentheses will be used anyway.

The answer, of course, is that the condition of your "if" clause is
not true. In the overwhelming majority of the cases, people do not
use parentheses to clarify the order of evaluation that is guaranteed
by C's grammar rules. They only use them in the cases where they feel
that there's a significant chance of confusion.

Those are the cases we're talking about! That is:

<< >> & | ^

Maybe add == != and < <= >= > is someone wants to take advantage of
their different levels, but I guess 99% wouldn't even know about what.

Most of the rest, there tends to be agreement across languages:

school arithmetic group - comparisons - logical and/or

I haven't included ?: as that's too weird.

So what is your question? I had thought that you meant to ask why
Ritchie defined the precedences that way, but apparently that's
not what you meant.

Do you even have a question? Is there anything anyone could tell
you that you don't think you already know?

If you have a question, can you restate it in unambiguous terms?
If not, what are we talking about?

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Fri, 29 May 2026 05:20:20 -0500, BGB wrote:

To be excluded from being syntactic sugar, it needs to be something
that is not generally possible to express within the base language.

So, for example: Things like operator overloading or classes are
syntactic sugar IMO, as what they do can be expressed in C, even if
a lot less pretty (or far from an idiomatic style).

I would not consider exceptions or RTTI as syntactic sugar, because
these involve things that do not map to native C.

But surely *anything* that ?is not generally possible to express
within the base language? woud ?not map to native C?.

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

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>

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 5/29/2026 7:58 AM, Bonita Montero wrote:

Am 29.05.2026 um 11:15 schrieb BGB:

Like, if one doesn't care that the compiler takes a long time to run
and the EXE is needlessly large, maybe OK, not great if one does care...

Binary size doesn't matter with Windows.

On a typical modern desktop PC...

Does still get annoying if it is needlessly large for no good reason.

Even if, yeah, modern PC will not care much about loading a 50 or 100MB
EXE file...

Having to spend minutes or more waiting for the compiler would
seriously hurt momentum for many tasks.

Use C++20 modules and parallel builds.

Possibly, I have my reasons, and not all of my current development is
limited to PC class systems.

Say, for example, if the Boot ROM requires keeping everything under 32K.

C++ was designed for large scale program development.
With 32K-systems you can stick with C.

There are intermediate options, where ones' RAM is measured in MB.


Or, basically, say imagine writing software on something where CPU
speeds and RAM sizes are basically similar to what things were like in
the 1990s.

Comparably, a desktop PC is much faster, and with almost limitless RAM.


Well, and one thing I am often messing with:
Well, I am using a PE/COFF variant...
But, the OS is not on Windows, and the ISA is not x86 based, ...
Still has EXE's and DLL's though.

Can't use C++ there, because no (native) C++ compiler exists.
Well, except if using GCC to generate RV64G; can run RV64G on it;
But, RV64G's performance is lacking, and the ELF files are bloated.
Kinda sucks when a significant part of the binary is just metadata.


Then again, the PE variant is non-standard:
No MZ stub;
LZ4 compression;
Mostly using 64-byte section alignment;
And a FileOffset==RVA constraint, ...
Various structures have been tweaked;
...


Well, and the format is itself an offshoot of a WinCE variant of the
format rather than from mainline Windows. Well, imagine an OS that sort
of took design inspiration both from WinCE and the Unix family OS's.

And ended up with a CLI experience kinda similar to Cygwin. And a very
crap attempt at making a GUI (that mostly just launches with a terminal
window that can be used to start other programs).


Well, a basic view of my crappy GUI can be seen here: https://www.youtube.com/watch?v=HAyMDRzxYzY

Though, the point of this video was more Doom but with the musical notes replaced with DTMF-like tones (but still having octaves and similar so
it at least sorta sounds like music). As sort of a bit of hackery with
the MIDI playback code (tweaking out the FM synthesis to to play DTMF
tones rather than the normal FM instruments).

Well, that and another recent-ish video of Doom modified to sorta
resemble the monochrome style of "Return of the Obra Dinn" (well, and
also this Doom port also has a 3D glasses mod, and 3D+Obra which
actually works pretty OK, ...).

...



--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Am 30.05.2026 um 01:20 schrieb Lawrence D?Oliveiro:

But they still don?t have ?try-finally?.

There's RAII:

#pragma once
#include <utility>
#include <concepts>
#include "nui.hpp"

template<std::invocable Fn>
struct defer final
{
defer( Fn &&fn, bool enabled = true ) :
m_fn( std::forward<Fn>( fn ) ),
m_enabled( enabled )
{
}
defer( defer const & ) = delete;
void operator =( defer const & ) = delete;
~defer() noexcept( std::is_nothrow_invocable_v<Fn> )
{
if( m_enabled ) [[likely]]
m_fn();
}
template<typename ... Fns>
bool operator ()( defer<Fns> &... additional ) noexcept( std::is_nothrow_invocable_v<Fn> && (std::is_nothrow_invocable_v<Fns> &&
...) )
{
if( !m_enabled ) [[unlikely]]
return false;
m_enabled = false;
m_fn();
return (additional() && ...);
}
template<typename ... Fns>
void disable( defer<Fns> &... additional ) noexcept
{
m_enabled = false;
(additional.disable(), ...);
}
template<typename ... Fns>
void enable( defer<Fns> &... additional ) noexcept
{
m_enabled = true;
(additional.enable(), ...);
}
private:
NO_UNIQUE_ADDRESS Fn m_fn;
bool m_enabled;
};

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

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.

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 30/05/2026 03:02, Keith Thompson wrote:

Bart <bc@freeuk.com> writes:

On 30/05/2026 01:31, James Kuyper wrote:

On 2026-05-29 18:52, Keith Thompson wrote:

Bart <bc@freeuk.com> writes:

...

Of course, I want the answer to be that there isn't any point if
parentheses will be used anyway.

The answer, of course, is that the condition of your "if" clause is
not true. In the overwhelming majority of the cases, people do not
use parentheses to clarify the order of evaluation that is guaranteed
by C's grammar rules. They only use them in the cases where they feel
that there's a significant chance of confusion.

Those are the cases we're talking about! That is:

<< >> & | ^

Maybe add == != and < <= >= > is someone wants to take advantage of
their different levels, but I guess 99% wouldn't even know about what.

Most of the rest, there tends to be agreement across languages:

school arithmetic group - comparisons - logical and/or

I haven't included ?: as that's too weird.

So what is your question? I had thought that you meant to ask why
Ritchie defined the precedences that way, but apparently that's
not what you meant.

You seem to have a problem with context. I was replying to JK who was
replying to a quote of mine from within one of your posts (maybe he's killfiled me so couldn't respond directly).

There was no question posted. He suggested that most of the time,
parentheses are not used and gave examples using * and +.

My original remarks were about the widespread use of parentheses to
clarify the grouping of operators with the more obscure priorities, and
my reply addressed that.

See also the examples I posted a few minutes ago involving >> & and ^.

That is, if you are interested in my point, which I doubt. You seem more intent on some personal campaign.

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 29/05/2026 22:16, BGB wrote:

On 5/29/2026 6:22 AM, David Brown wrote:

On 29/05/2026 12:20, BGB wrote:

On 5/29/2026 2:52 AM, Janis Papanagnou wrote:

On 2026-05-28 11:57, BGB wrote:

On 5/28/2026 2:18 AM, Janis Papanagnou wrote:

On 2026-05-28 01:49, BGB wrote:

[...]

But, not really an "easy" way to avoid bloat, other than to write
code specifically for what cases are relevant; while also avoiding
needless duplication and copy paste (where, overuse of copy/paste
can also lead to bloat; along with turning the code into an ugly
mess).

Hmm.. - as said, the during very early days there were issues; I
recall on one platform duplication of template code in more that
one source unit. And/or some environmental hacks (of the compiler)
to deposit template code for linking. In the later days I've not
seen such immature things anymore.

Possibly, a lot could depend on how one is counting things as well.


In a lot of cases when using GCC, I end up using:
ÿÿ -ffunction-sections -fdata-sections -Wl,-gc-sections

On many targets, "-fdata-sections" can lead to noticeably larger and
slower code because it effectively eliminates section anchor
optimisations.ÿ It does not negatively affect x86 AFAICS, because x86
does not use section anchors.

<https://godbolt.org/z/zeoq41Y7d>

With -fsection-anchors (enabled with optimisation on targets that
support it - generally RISCy load/store architectures), program-
lifetime variables are kept together in a lump (as though they were in
a struct) and often addressed by a pointer to that pretend struct.
Thus if a function accesses two variables "a" and "b", instead of
having to load the addresses of each of "a" and "b" into separate
registers, it loads an "anchor" into one register and accesses the
variables with reg+offset addressing.

I've seen "-fdata-sections" used regularly in embedded systems - it is
almost always a bad idea.

("-ffunction-sections" is often very helpful to reduce code image
size, so keep that one.)

Both seem to help on x86, x86-64, and also on RISC-V, at making GCC's
output at least sorta space-comparable to my own compilers.

The merit of "-fdata-sections" is mostly that it eliminates unused
global variables; whereas "-ffunction-sections" eliminates unreachable functions.

That is the point of them, yes. "-ffunction-sections" can be useful at removing unused code from more general code. For microcontrollers,
SDK's and manufacturers' driver code will normally contain a large
number of functions that can be eliminated in this way, saving a lot of
code space.

However, in practice, "-fdata-sections" rarely eliminates a significant
amount - most programs do not have large amounts of statically-allocated
data that is not used. Gcc, and I think most other compilers, put the
static lifetime data for each translation unit in its own section, so if
no data from a translation unit is used it will be eliminated at link
time even with -fno-data-sections. And of course it makes no difference
for heap data or stack data.

In my testing, "-ffunction-sections" is absolutely worth using (on
targets where code space is relevant - there's no need for PC software).
On some targets, it may mean a few lost opportunities for shorter
jump/call instructions between functions in the same translation unit,
but the cost is rarely anything more than a slightly longer link time.
But "-fdata-sections" typically gives almost no ram space savings, and
makes code bigger and slower.

As I noted, gcc on x86 does not support section anchors, so there is not likely to be much code cost for -ffdata-sections.

Where section anchors shine - and where -fdata-sections therefore has
cost - is when a function needs to access more than one piece of static lifetime data defined in the same translation unit (or another
translation unit if you are using LTO). That happens a lot in embedded
ARM programming at least. I don't know about RISC-V. If the target
normally uses a "small data section" for ram (I know this is common on PowerPC), then there is, in effect, a program-wide section anchor
already. So it is possible that it relatively few targets have section anchors - but the 32-bit ARM on gcc is a vastly popular choice in the
embedded world, so it is important to understand the cost of this
compiler flag for that target at least.

Neither is needed with my own compiler, which compiles things in a way
such that it eliminates anything that is unreachable.

[...]

That might be the case for a very simplistic compiler.ÿ With an
optimising compiler, these extra variables will quickly be eliminated.
If the compiler has a good scheduling model of the device, it do
whatever instruction scheduling works best for that processor.ÿ If the
model is not good enough, it will be suboptimal.ÿ I would not,
however, expect any different in the generated code for the two code
snippets.

Sometimes this kind of "manual optimisation" is helpful when you have
to try to get efficient results from a weak compiler, however.

Possibly, but this sort of thing can help with both BGBCC and with MSVC
IME

I don't tend to think of MSVC as a highly optimising compiler - but it
is not a tool I have much use for, as it does not handle the targets I
need. When I have sometimes looked at the generated code on godbolt, it
has not impressed me at all. So it could well fall into the "helpful
when using a weaker compiler" category.

Usual strategy is to try to limit how much code is written, and
also to avoid doing things in ways that result in too much code, or >>>>> too much cruft.

Best to avoid both copy paste when reasonable, and sticking
anything non-trivial in macros.

We avoided macros if possible.

They are de-facto for constants and similar, but for longer stuff is
better avoided.

Macros are rarely the best way to define constants.ÿ They are needed
if you are using the constants for pre-processor stuff like
conditional compilation.ÿ But generally you get clearer code, better
typing, and potentially several other benefits from using alternative
choices like "enum" (even for stand-alone integer constants), "static
const" variables, and in C23, "constexpr" variables.ÿ There's no doubt
that a lot of code /does/ use macros for constants, but I view it as a
relic of the past rather than good coding practice.

They are traditional...

Like:
ÿ static const double M_PI = 3.14159265358979;

Could also make sense, but people don't do usually this, they usually
use macros...

They should not do so (IMHO, of course). Yes, macros are traditional -
but there are no plus sides to using them for this kind of thing.
(There are no plus sides to using all-caps either, but people do that too.)

(I'm snipping all the details of your own C compiler, because there is
very little I can comment on.)

But, things can be considered in relative terms:
Like, C++ may carry various penalties vs C.

I don't find C++ carries noticeably penalties compared to C, for my
embedded work.ÿ But I do disable exceptions and RTTI - exceptions may
have very little run-time time overhead, but the unwind tables can be
significant when code size is important in small systems.

Yes, that is the main thing.
ÿ They carry zero performance penalty in practice;
ÿ But, have a non-zero penalty for image size.

Not enough to be a deal-breaker towards using them if they are used, but enough that one wants them disabled if not used...

Agreed.

(I could also note that I make heavy use of templates in C++ code - it
often leads to smaller and faster results.)





--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

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.


--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

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"?

Of course, I want the answer to be that there isn't any point if
parentheses will be used anyway.

There is a point, but it is history. That is, the "point" is of
those precedence levels is the history and evolution of the
language.

In PL/1 and 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.

- Dan C.


--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 2026-05-30 13:52, David Brown wrote:

On 29/05/2026 22:16, BGB wrote:

On 5/29/2026 6:22 AM, David Brown wrote:

On 29/05/2026 12:20, BGB wrote:

On 5/29/2026 2:52 AM, Janis Papanagnou wrote:

We avoided macros if possible.

They are de-facto for constants and similar, but for longer stuff is
better avoided.

Macros are rarely the best way to define constants.ÿ They are needed
if you are using the constants for pre-processor stuff like
conditional compilation.ÿ But generally you get clearer code, better
typing, and potentially several other benefits from using alternative
choices like "enum" (even for stand-alone integer constants), "static
const" variables, and in C23, "constexpr" variables.ÿ There's no
doubt that a lot of code /does/ use macros for constants, but I view
it as a relic of the past rather than good coding practice.

They are traditional...

Like:
ÿÿ static const double M_PI = 3.14159265358979;

Could also make sense, but people don't do usually this, they usually
use macros...

They should not do so (IMHO, of course).ÿ Yes, macros are traditional -
but there are no plus sides to using them for this kind of thing. (There
are no plus sides to using all-caps either, but people do that too.)

Because in early days Cpp constants have been used and Cpp-stuff often capitalized[*]. Our C++ coding rules back then had mandated lowercase
also for constants, but strangely some folks were so used to uppercase
Cpp literals that they disliked to write constants (as other objects)
in lowercase, and stated opinions were sometimes heated like religious
topics.

I wonder what lexical convention regular "C" (or C++) programmers here
use for constants nowadays.

Curiously I inspected my latest C-source to see what convention I've
actually followed recently. But I noticed that I had no hard constants
used at all; all parameters came from a configuration file and through
the command line interface. (That makes sense, I guess.)

Janis

[*] Strangely there were C-function-macros that were written lowercase,
though.

[...]

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

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.

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.





--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 30/05/2026 14:40, Janis Papanagnou wrote:

On 2026-05-30 13:52, David Brown wrote:

On 29/05/2026 22:16, BGB wrote:

On 5/29/2026 6:22 AM, David Brown wrote:

On 29/05/2026 12:20, BGB wrote:

On 5/29/2026 2:52 AM, Janis Papanagnou wrote:

We avoided macros if possible.

They are de-facto for constants and similar, but for longer stuff
is better avoided.

Macros are rarely the best way to define constants.ÿ They are needed
if you are using the constants for pre-processor stuff like
conditional compilation.ÿ But generally you get clearer code, better
typing, and potentially several other benefits from using
alternative choices like "enum" (even for stand-alone integer
constants), "static const" variables, and in C23, "constexpr"
variables.ÿ There's no doubt that a lot of code /does/ use macros
for constants, but I view it as a relic of the past rather than good
coding practice.

They are traditional...

Like:
ÿÿ static const double M_PI = 3.14159265358979;

Could also make sense, but people don't do usually this, they usually
use macros...

They should not do so (IMHO, of course).ÿ Yes, macros are traditional
- but there are no plus sides to using them for this kind of thing.
(There are no plus sides to using all-caps either, but people do that
too.)

Because in early days Cpp constants have been used and Cpp-stuff often capitalized[*]. Our C++ coding rules back then had mandated lowercase
also for constants, but strangely some folks were so used to uppercase
Cpp literals that they disliked to write constants (as other objects)
in lowercase, and stated opinions were sometimes heated like religious topics.

I wonder what lexical convention regular "C" (or C++) programmers here
use for constants nowadays.

Curiously I inspected my latest C-source to see what convention I've
actually followed recently. But I noticed that I had no hard constants
used at all; all parameters came from a configuration file and through
the command line interface. (That makes sense, I guess.)

Janis

[*] Strangely there were C-function-macros that were written lowercase, though.

I think there is a reasonable case for all-caps for macros that are
doing something "weird", as a warning to users. You know that it's
risky trying to write "MAX(a++, b++)", as it might evaluate one or both
of the parameter expressions twice. But if you also use all-caps for well-behaved macros, that dilutes the warning effect.

I use all-caps for define names that I expect to come from outside the
source files - like a command line flag "-DPROG_VARIANT=2" in a
makefile, and that kind of thing. That, to me, counts as a "weird" macro.

I am happy to use macros where they make sense, but I would not use a
macro if a static const, enum, static inline function, or constexpr
variable will do just as well.



--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 5/30/2026 6:52 AM, David Brown wrote:

On 29/05/2026 22:16, BGB wrote:

On 5/29/2026 6:22 AM, David Brown wrote:

On 29/05/2026 12:20, BGB wrote:

On 5/29/2026 2:52 AM, Janis Papanagnou wrote:

On 2026-05-28 11:57, BGB wrote:

On 5/28/2026 2:18 AM, Janis Papanagnou wrote:

On 2026-05-28 01:49, BGB wrote:

[...]

But, not really an "easy" way to avoid bloat, other than to write >>>>>> code specifically for what cases are relevant; while also avoiding >>>>>> needless duplication and copy paste (where, overuse of copy/paste >>>>>> can also lead to bloat; along with turning the code into an ugly
mess).

Hmm.. - as said, the during very early days there were issues; I
recall on one platform duplication of template code in more that
one source unit. And/or some environmental hacks (of the compiler)
to deposit template code for linking. In the later days I've not
seen such immature things anymore.

Possibly, a lot could depend on how one is counting things as well.


In a lot of cases when using GCC, I end up using:
ÿÿ -ffunction-sections -fdata-sections -Wl,-gc-sections

On many targets, "-fdata-sections" can lead to noticeably larger and
slower code because it effectively eliminates section anchor
optimisations.ÿ It does not negatively affect x86 AFAICS, because x86
does not use section anchors.

<https://godbolt.org/z/zeoq41Y7d>

With -fsection-anchors (enabled with optimisation on targets that
support it - generally RISCy load/store architectures), program-
lifetime variables are kept together in a lump (as though they were
in a struct) and often addressed by a pointer to that pretend struct.
Thus if a function accesses two variables "a" and "b", instead of
having to load the addresses of each of "a" and "b" into separate
registers, it loads an "anchor" into one register and accesses the
variables with reg+offset addressing.

I've seen "-fdata-sections" used regularly in embedded systems - it
is almost always a bad idea.

("-ffunction-sections" is often very helpful to reduce code image
size, so keep that one.)

Both seem to help on x86, x86-64, and also on RISC-V, at making GCC's
output at least sorta space-comparable to my own compilers.

The merit of "-fdata-sections" is mostly that it eliminates unused
global variables; whereas "-ffunction-sections" eliminates unreachable
functions.

That is the point of them, yes.ÿ "-ffunction-sections" can be useful at removing unused code from more general code.ÿ For microcontrollers,
SDK's and manufacturers' driver code will normally contain a large
number of functions that can be eliminated in this way, saving a lot of
code space.

However, in practice, "-fdata-sections" rarely eliminates a significant amount - most programs do not have large amounts of statically-allocated data that is not used.ÿ Gcc, and I think most other compilers, put the static lifetime data for each translation unit in its own section, so if
no data from a translation unit is used it will be eliminated at link
time even with -fno-data-sections.ÿ And of course it makes no difference
for heap data or stack data.

The main place it makes a difference is global arrays from a translation
unit that is included, but for functions that are not included.

Also functions with large static arrays.


void SomeFunc()
{
static char buf[4096];
...
}

Where, say, eliminating SomeFunc does not necessarily eliminate buf.

In my testing, "-ffunction-sections" is absolutely worth using (on
targets where code space is relevant - there's no need for PC software).
ÿOn some targets, it may mean a few lost opportunities for shorter jump/call instructions between functions in the same translation unit,
but the cost is rarely anything more than a slightly longer link time.
But "-fdata-sections" typically gives almost no ram space savings, and
makes code bigger and slower.

As I noted, gcc on x86 does not support section anchors, so there is not likely to be much code cost for -ffdata-sections.

Where section anchors shine - and where -fdata-sections therefore has
cost - is when a function needs to access more than one piece of static lifetime data defined in the same translation unit (or another
translation unit if you are using LTO).ÿ That happens a lot in embedded
ARM programming at least.ÿ I don't know about RISC-V.ÿ If the target normally uses a "small data section" for ram (I know this is common on PowerPC), then there is, in effect, a program-wide section anchor
already.ÿ So it is possible that it relatively few targets have section anchors - but the 32-bit ARM on gcc is a vastly popular choice in the embedded world, so it is important to understand the cost of this
compiler flag for that target at least.

It depends on the way it is built.


A lot of times though (for non-relocatable static-linked binaries) it
mostly tends to use AUIPC+LD or AUIPC+ST pairs to access global
variables. There is a Global Pointer that needs to be loaded when the
binary is started, unclear what it is used for exactly.


in PIC/PIE binaries, it uses AUIPC+ADDI to get a GOT pointer and then
uses the GOT pointers to access global variables (via fetching the
address of the variable from the GOT).


Can note that BGBCC targeting RV works differently, instead using GP to
access global variables, and clustering the commonly accessed global
variables around GP (GP is initialized to point towards at the start of
the ".data" section for the main EXE at program startup, though in my
ABI this may actually be a copy allocated elsewhere in RAM, and not
actually pointing at the version of the section located in the original
PE image; note that the loader also applies base relocs for the data
section separately when locating it; in effect the base relocs being internally partitioned per-section, rather than the per-page
partitioning scheme used in the original PE/COFF).


For my target, I mostly end up needing to use PIE binaries with GCC, as
it needs to be able to load the binary at different locations.

However, I am using a custom C library, as I (still) haven't managed to
get the "ld-linux.so" stuff working. Not yet figured out whatever poorly-documented arcane dark magic is needed to get this part working.


As noted, my compiler's output (including for plain RISC-V) using
PE/COFF, which was also the native format for the OS.


Note that for Linux binaries in this case it would mimics the Linux
syscall interface; though as I hadn't gotten very far with the PIE
loader, most of the syscalls are still not implemented.


My own makeshift OS has a different syscall mechanism, ironically using
the same registers, but a syscall number of -1 (Linux uses positive
syscall numbers).

They work in different ways, IIRC:
X10..X15: Arg1..Arg6
X16: Unused, 0
X17: Syscall Number (always positive)

In my case, syscalls took a different form, IIRC:
X10: Object ID (Handle)
X11: Method Number (Integer)
X12: Method Args List (Pointer)
X13: Return Value (Pointer)
X14..X16: Unused, 0 (RV)
X17: Holds -1 (RV).

In this case, system calls and many OS APIs take the form of object
method calls, with a special range of low-numbered object IDs (Eg, 0 or
NULL) mapping to core/basic syscalls.


But, yeah, some OS APIs would take the form of objects which would be
wrapped in a VTable struct, say:
SomeApi_Vt **api;
(*Api)->ApiMethod(api, arg1, arg2);

In this case, well, there were two major ways of requesting APIs:
Pairs of EIGHTCC values, for some public APIs
Or as FOURCC's for shorthand (zero padded to 64 bits).
As a UUID / GUID:
Primarily used for local / private interfaces.


Well, people probably can't guess where this mechanism originally came
from...


Well, not exactly the same as the inspiration, as there is no IDL
compiler involved, mostly just bare C structs representing the VTables.
There is essentially a blob of generic reusable method-wrappers (and a
whole generic reusable VTable) that is shared across many of these
objects, so calling a method on an object then just sorta translates it
into the corresponding system call to invoke that method slot.

Well, and this mechanism being part of why (for RV) I stuck with an ABI variant that passes everything in X registers (separate X and F
registers would make a big ugly mess for this whenever a method has a floating-point argument).

Neither is needed with my own compiler, which compiles things in a way
such that it eliminates anything that is unreachable.

[...]

That might be the case for a very simplistic compiler.ÿ With an
optimising compiler, these extra variables will quickly be
eliminated. If the compiler has a good scheduling model of the
device, it do whatever instruction scheduling works best for that
processor.ÿ If the model is not good enough, it will be suboptimal.
I would not, however, expect any different in the generated code for
the two code snippets.

Sometimes this kind of "manual optimisation" is helpful when you have
to try to get efficient results from a weak compiler, however.

Possibly, but this sort of thing can help with both BGBCC and with
MSVC IME

I don't tend to think of MSVC as a highly optimising compiler - but it
is not a tool I have much use for, as it does not handle the targets I
need.ÿ When I have sometimes looked at the generated code on godbolt, it
has not impressed me at all.ÿ So it could well fall into the "helpful
when using a weaker compiler" category.

Depends on what target I am building for:
Windows Native: Typically MSVC
WSL: Usually GCC or Clang
Seems to have: GCC 13.2.0; Clang 18.1.3
RISC-V GCC: Also 13.2.0 (also via WSL)
Linux: Typically GCC

I rarely much use Cygwin anymore, as it was mostly rendered obsolete by
WSL (on Win10 or similar).
Though, Cygwin may still be relevant on Win7 or WinXP systems.

For BGBCC, it can build both on native Windows and on Linux/WSL (though recently noted that this build was broken, mostly by GCC and Clang being
more pedantic about missing prototypes, and a few prototypes were being
missed by my function-prototype mining tool). Went and fixed this, but
haven't posted this yet.


As for optimizing in MSVC, yeah, it is in the area of not terrible, but
not super clever either.

If one expects the sort of high-level code-rewriting cleverness that GCC
or Clang often does, one will be disappointed.

But, sometimes, the main "heavy hitter" optimizations are things like constant-folding and register allocation, which it does do effectively.

Though, both MSVC and BGBCC seem to use one sort of strategy for
register allocation:


Static assign things to callee-save registers and use remaining
registers for dynamic allocation within basic-blocks. Variables with
finite non-overlapping lifetimes (that do not cross basic-block
boundaries) may potentially share a register (this more generally
applies to things like temporaries).

And, GCC and Clang use another: Assign dynamically but carry values
across basic-block boundaries along control-flow paths.

Both tend to give different patterns though, and seem to favor different
types of code.

Usual strategy is to try to limit how much code is written, and
also to avoid doing things in ways that result in too much code,
or too much cruft.

Best to avoid both copy paste when reasonable, and sticking
anything non-trivial in macros.

We avoided macros if possible.

They are de-facto for constants and similar, but for longer stuff is
better avoided.

Macros are rarely the best way to define constants.ÿ They are needed
if you are using the constants for pre-processor stuff like
conditional compilation.ÿ But generally you get clearer code, better
typing, and potentially several other benefits from using alternative
choices like "enum" (even for stand-alone integer constants), "static
const" variables, and in C23, "constexpr" variables.ÿ There's no
doubt that a lot of code /does/ use macros for constants, but I view
it as a relic of the past rather than good coding practice.

They are traditional...

Like:
ÿÿ static const double M_PI = 3.14159265358979;

Could also make sense, but people don't do usually this, they usually
use macros...

They should not do so (IMHO, of course).ÿ Yes, macros are traditional -
but there are no plus sides to using them for this kind of thing. (There
are no plus sides to using all-caps either, but people do that too.)

It is more tradition...

My conventions, as noted, are sorta like:
Macros / Constants: All caps;
Functions:
LIBNAME_SysSys_FirstLetterCaps //externally callable within LIBNAME
libname_subsys_nocaps //usually private to a subsystem
LIBNAME_FirstLetterCaps //main API for a private library
somefunction //C library convention
libname_somefunction //some OS API stuff
libFirstLetterCaps //GL-like, common for public APIs
FirstLetterCaps //was common in Win32 API, unused
Conventions are looser for standalone programs, but:
somename, some_name, ... //small programs
S_SomeFunc //id Software like, letter for major subsystem


In my own makeshift OS, had used OpenGL like naming for a lot of OS APIs.
tkWhatever //TestKern OS APIs
tkgdiWhatever //TKGDI: Basically Graphics/GUI stuff


As noted, some amount of these are implemented as object wrappers.
Likewise for my OpenGL implementation.

Though, OpenGL is more annoying in that it usually works via a "GetProcAddress()" type mechanism, so you need to fetch each function
pointer internally (and provide a lookup mechanism for each function).
Where, the main (static linked) part of the GL API is effectively
wrapper functions over function pointers gained via said
"GetProcAddress()" mechanism, which then go into the userland
implementation of those functions (typically, with part of the GL API
running in userland, and a backend part that runs "elsewhere", such as
in the GUI process, and is reached over an Object / COM interface).


FWIW, I didn't design this part of the GL API, but if I had, probably
would have just used COM objects internally.

Still better IMO to provide a nice C API wrapper over said COM objects
though, rather than go the DirectX route and be like "Hey, application
code, have fun with these here bare COM objects!".


Exposing bare COM objects and GUIDs in a public API is poor design IMO.

Well, even if in effect many of the API calls are just:
void apiDoSomething()
{ (*someapi_context)->DoSomething(someapi_context); }


This differs some from Linux APIs, which often like sharing bare
functions and variables across API boundaries (so, no real wall of
separation between the library and application in this sense).


These partly runs into an issue in that in my case, BGBCC (like MSVC)
requires being explicit about DLL imports and exports, and sharing
global variables across DLL boundaries is generally discouraged.

Note that the DLL mechanism doesn't actually support sharing global
variables directly, so if you try to share a global across a DLL
boundary, what you actually get is a hidden function-call that returns a pointer to the variable.

__declspec(dllimport) int somevar; //not actually a variable.

x=somevar;
Is more like:
x=*(int *)(__get_somevar());

But, generally discouraged.


Sharing variables across DLLs is bad practice IMO, and ideally only
sharing functions that represent a public API (and not, "whatever random
stuff happens to be in the library"). Contrast to the Linux "shared
object" approach which does tend to take more of a "share everything" approach, and libraries tend to not maintain as string of a library/application separation.

Well, and then Cygwin goes and tries to fake Linux behavior on top of
DLLs (in which case a large library can also find itself running into
the hard limit on the maximum number of DLL exports).

...


Can note that I had approached C library linking in a different way from MSVC/Windows:
Windows:
Main EXE and every DLL get their own static-linked C library.
Can opt into a shared DLL for the C library, but this adds wonk.
BGBCC+TestKern:
Main EXE gets a static-linked C library;
Exports a COM interface that DLLs can use;
DLLs get a static linked C-library stub;
Invokes main C library via a hidden COM interface.


This basically allows things like malloc/free and stdio to work across
DLL boundaries (unlike Windows where each gets their own local heap and
stdio, and trying to invoke a pointer from one DLL in another tends to
cause stuff to explode).

Granted, the DLLs effectively pulling the C library from the main EXE
via COM objects may seem a little unorthodox, but it seemed like the
best way to address my use cases.

(I'm snipping all the details of your own C compiler, because there is
very little I can comment on.)

But, things can be considered in relative terms:
Like, C++ may carry various penalties vs C.

I don't find C++ carries noticeably penalties compared to C, for my
embedded work.ÿ But I do disable exceptions and RTTI - exceptions may
have very little run-time time overhead, but the unwind tables can be
significant when code size is important in small systems.

Yes, that is the main thing.
ÿÿ They carry zero performance penalty in practice;
ÿÿ But, have a non-zero penalty for image size.

Not enough to be a deal-breaker towards using them if they are used,
but enough that one wants them disabled if not used...

Agreed.

(I could also note that I make heavy use of templates in C++ code - it
often leads to smaller and faster results.)

Curious...


I had tended to use the "write everything one off for the task at hand" approach, but this is a higher-effort approach.

...


--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Bart <bc@freeuk.com> writes:

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's very different from your original question, which is quoted
above. Your original question, with its use of the past tense,
seemed clearly (to me) to be about how C was originally designed.

I don't have a straightforward yes or no answer to your restated
question.

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.

Nothing about the current rules particularly bothers me. There are
no objective criteria for deciding what the rules *should* be.
Even having multiplication bind more tightly than addition is
fundamentally an arbitrary choice (though one that's almost
universally recognized, even outside the context of programming
languages).

Of course all C implementations must implement the expression
syntax as it's defined by the standard, and any changes in future
editions of the standard would be impractical. As a programmer,
I don't have to be as strict; I can add parentheses when writing
code, and I can look up the rules as needed when reading code.

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)];

Yes, they can, and I personally tend to agree that they should.

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.

When designing a new language, there are real advantages in strictly
imitating C's rules, just because so many programmers are familiar
with them. (I would have been silly for C++ or Objective-C to
change the precedence rules, even to improve them.) But there
are also real advantages in using precedence rules that are better
(e.g., simpler) than C's. It depends on the nature of the language.
It could be an interesting discussion for comp.lang.misc.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Sat, 30 May 2026 12:01:27 +0100, Bart wrote:

It doesn't beed << >> to be in a distinct group from multiply or add
groups.

But it is also not clear because the part after >> is sprawling.

It?s a counterexample to your claim that ?<< >> [don?t need] to be in
a distinct group?, isn?t it?

You'd want it like this:

Because they are in a distinct group, you don?t need it like this.

Remove ambiguity in the mind of the reader? Leader to fewer
surprises when a new term needs to be added?

The new terms will most likely fit into the existing ones in the
natural way.

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 2026-05-31 01:43, Keith Thompson wrote:

Bart <bc@freeuk.com> writes:

[...]

[...]

C's operator precedence rules are complicated and arguably flawed.

I'd say that just the (known) flaw makes them (slightly) complicated;
so you need to remember that "flaw" (or "inconsistency") to be safe.
The rest is completely sensible. And even if one doesn't have a table
to look up the precedences they mostly can be derived (presuming one
has a feeling for the underlying logic of these things or experiences
from other related areas).

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.

Nothing about the current rules particularly bothers me. There are
no objective criteria for deciding what the rules *should* be.

There are. (What I called above as "derived underlying logic".) Some
aspects have already been formulated in this and other threads here.
But maybe not obvious to recognize without background in mathematics,
logic, or CS.

Even having multiplication bind more tightly than addition is
fundamentally an arbitrary choice

(Now opinions are getting really strange; in the above stated sense.)

(though one that's almost
universally recognized, even outside the context of programming
languages).

[...]

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)];

Yes, they can, and I personally tend to agree that they should.

The more complex the expressions are the more structure they need.

IMO, the parenthesis above make precedence clear (if unknown!), but
are not contributing to readability. It would have made more sense
to separate the sub-expression within the [...] in an own object to
enhance readability and to more easily understand what's going on.

To emphasize; not the precedences are the problem above, but the
complexity of the expression in connexion with lack of structuring.

[...]

When designing a new language, there are real advantages in strictly imitating C's rules, just because so many programmers are familiar
with them.

Huh? - How that? - Are you saying here that practically only C-like
languages are in common use? - But even if so; there's quite some
languages with differing precedence rules, not C-based, and without
such a flaw like the one being discussed. - When designing a *new*
language I'd certainly choose one of the sensible precedence rules,
and just without those obvious flaws. (And not use "C" as base, of
course.)

(I would have been silly for C++ or Objective-C to
change the precedence rules, even to improve them.) But there
are also real advantages in using precedence rules that are better
(e.g., simpler) than C's.

Or - with reference to that flaw - just more consistent.

Consistent systems are inherently simpler, in the sense of easier to
understand and thus more straightforward to use. A precondition for
that is, as said, at least a basic understanding of such things.

It depends on the nature of the language.
It could be an interesting discussion for comp.lang.misc.

Janis


--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:

On 2026-05-31 01:43, Keith Thompson wrote:

Bart <bc@freeuk.com> writes:

[...]

[...]
C's operator precedence rules are complicated and arguably flawed.

I'd say that just the (known) flaw makes them (slightly) complicated;
so you need to remember that "flaw" (or "inconsistency") to be safe.
The rest is completely sensible. And even if one doesn't have a table
to look up the precedences they mostly can be derived (presuming one
has a feeling for the underlying logic of these things or experiences
from other related areas).

Reasonable, but I feel the need to say that that's your personal
opinion. You seem to think that C's precedence rules have one and
only one flaw, and a set of rules with that flaw corrected would
be ideal.

I don't even necessarily disagree, but others are likely to have
different opinions, and those opinions might be perfectly valid.

I don't want to make a huge deal out of this. I honestly don't have
a strong opinion myself. I usually find dealing with the rules
as they exist to be a much better use of my time and attention --
and I don't mean that as a criticism of anyone who choose to think
about alternatives.

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.
Nothing about the current rules particularly bothers me. There are
no objective criteria for deciding what the rules *should* be.

There are. (What I called above as "derived underlying logic".) Some
aspects have already been formulated in this and other threads here.
But maybe not obvious to recognize without background in mathematics,
logic, or CS.

Even having multiplication bind more tightly than addition is
fundamentally an arbitrary choice

(Now opinions are getting really strange; in the above stated sense.)

Mathematical notation almost universally has multiplication binding
more tightly than addition. It's consistent because the consistency
itself has big advantages so that you can write x + y * z (or x +
y ? z) and everyone knows what you mean. Strict left-to-right
evaluation would also have been a valid choice. (I don't know the
history, but it probably goes back several centuries.)

(though one that's almost
universally recognized, even outside the context of programming
languages).
[...]

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)];

Yes, they can, and I personally tend to agree that they should.

The more complex the expressions are the more structure they need.

IMO, the parenthesis above make precedence clear (if unknown!), but
are not contributing to readability. It would have made more sense
to separate the sub-expression within the [...] in an own object to
enhance readability and to more easily understand what's going on.

To emphasize; not the precedences are the problem above, but the
complexity of the expression in connexion with lack of structuring.

[...]

When designing a new language, there are real advantages in strictly
imitating C's rules, just because so many programmers are familiar
with them.

Huh? - How that? - Are you saying here that practically only C-like
languages are in common use?

Huh? No, I didn't say that at all.

I suggest that if you're designing a somewhat C-like language,
sticking to C's precedence rules has advantages due to programmer
familiarity. Even for a language that's not particularly C-like,
but that has C-like expressions, the designer might consider
following C's rules.

Or not.

- But even if so; there's quite some
languages with differing precedence rules, not C-based, and without
such a flaw like the one being discussed. - When designing a *new*
language I'd certainly choose one of the sensible precedence rules,
and just without those obvious flaws. (And not use "C" as base, of
course.)

Certainly.

(I would have been silly for C++ or Objective-C to
change the precedence rules, even to improve them.) But there
are also real advantages in using precedence rules that are better
(e.g., simpler) than C's.

Or - with reference to that flaw - just more consistent.

Consistent systems are inherently simpler, in the sense of easier to understand and thus more straightforward to use. A precondition for
that is, as said, at least a basic understanding of such things.

Ah, but consistent with what? Internal consistency and consistency
with existing practice are not necessarily the same thing.

It depends on the nature of the language.
It could be an interesting discussion for comp.lang.misc.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

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.



--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 30/05/2026 22:48, BGB wrote:

On 5/30/2026 6:52 AM, David Brown wrote:

On 29/05/2026 22:16, BGB wrote:

On 5/29/2026 6:22 AM, David Brown wrote:

On 29/05/2026 12:20, BGB wrote:

On 5/29/2026 2:52 AM, Janis Papanagnou wrote:

On 2026-05-28 11:57, BGB wrote:

On 5/28/2026 2:18 AM, Janis Papanagnou wrote:

On 2026-05-28 01:49, BGB wrote:

[...]

But, not really an "easy" way to avoid bloat, other than to write >>>>>>> code specifically for what cases are relevant; while also
avoiding needless duplication and copy paste (where, overuse of >>>>>>> copy/paste can also lead to bloat; along with turning the code
into an ugly mess).

Hmm.. - as said, the during very early days there were issues; I
recall on one platform duplication of template code in more that
one source unit. And/or some environmental hacks (of the compiler) >>>>>> to deposit template code for linking. In the later days I've not
seen such immature things anymore.

Possibly, a lot could depend on how one is counting things as well.


In a lot of cases when using GCC, I end up using:
ÿÿ -ffunction-sections -fdata-sections -Wl,-gc-sections

On many targets, "-fdata-sections" can lead to noticeably larger and
slower code because it effectively eliminates section anchor
optimisations.ÿ It does not negatively affect x86 AFAICS, because
x86 does not use section anchors.

<https://godbolt.org/z/zeoq41Y7d>

With -fsection-anchors (enabled with optimisation on targets that
support it - generally RISCy load/store architectures), program-
lifetime variables are kept together in a lump (as though they were
in a struct) and often addressed by a pointer to that pretend
struct. Thus if a function accesses two variables "a" and "b",
instead of having to load the addresses of each of "a" and "b" into
separate registers, it loads an "anchor" into one register and
accesses the variables with reg+offset addressing.

I've seen "-fdata-sections" used regularly in embedded systems - it
is almost always a bad idea.

("-ffunction-sections" is often very helpful to reduce code image
size, so keep that one.)

Both seem to help on x86, x86-64, and also on RISC-V, at making GCC's
output at least sorta space-comparable to my own compilers.

The merit of "-fdata-sections" is mostly that it eliminates unused
global variables; whereas "-ffunction-sections" eliminates
unreachable functions.

That is the point of them, yes.ÿ "-ffunction-sections" can be useful
at removing unused code from more general code.ÿ For microcontrollers,
SDK's and manufacturers' driver code will normally contain a large
number of functions that can be eliminated in this way, saving a lot
of code space.

However, in practice, "-fdata-sections" rarely eliminates a
significant amount - most programs do not have large amounts of
statically-allocated data that is not used.ÿ Gcc, and I think most
other compilers, put the static lifetime data for each translation
unit in its own section, so if no data from a translation unit is used
it will be eliminated at link time even with -fno-data-sections.ÿ And
of course it makes no difference for heap data or stack data.

The main place it makes a difference is global arrays from a translation unit that is included, but for functions that are not included.

Also functions with large static arrays.

void SomeFunc()
{
ÿ static char buf[4096];
ÿ ...
}

Where, say, eliminating SomeFunc does not necessarily eliminate buf.

Yes, if you have such code but want to eliminate it, then
-fdata-sections would definitely benefit. I have not seen such code in practice (at least not with very big static arrays, and that also was
not an essential part of the program). But of course I have only seen a microscopic part of all C code written - if you come across this sort of thing, then I appreciate your point.

(There are several ways to make this more "friendly" to builds that need
to be compact, such as putting the buffer and/or SomeFunc in a separate
file or giving it a specific section of its own.)

In my testing, "-ffunction-sections" is absolutely worth using (on
targets where code space is relevant - there's no need for PC
software). ÿÿOn some targets, it may mean a few lost opportunities for
shorter jump/call instructions between functions in the same
translation unit, but the cost is rarely anything more than a slightly
longer link time. But "-fdata-sections" typically gives almost no ram
space savings, and makes code bigger and slower.

As I noted, gcc on x86 does not support section anchors, so there is
not likely to be much code cost for -ffdata-sections.

Where section anchors shine - and where -fdata-sections therefore has
cost - is when a function needs to access more than one piece of
static lifetime data defined in the same translation unit (or another
translation unit if you are using LTO).ÿ That happens a lot in
embedded ARM programming at least.ÿ I don't know about RISC-V.ÿ If the
target normally uses a "small data section" for ram (I know this is
common on PowerPC), then there is, in effect, a program-wide section
anchor already.ÿ So it is possible that it relatively few targets have
section anchors - but the 32-bit ARM on gcc is a vastly popular choice
in the embedded world, so it is important to understand the cost of
this compiler flag for that target at least.

It depends on the way it is built.

A lot of times though (for non-relocatable static-linked binaries) it
mostly tends to use AUIPC+LD or AUIPC+ST pairs to access global
variables. There is a Global Pointer that needs to be loaded when the
binary is started, unclear what it is used for exactly.

If you have a global pointer, then it will probably be used for
gp+offset access to global data, eliminating the need for section anchors.

I have not used RISC-V, and am not familiar with its details. I can see
from godbolt that when -fdata-sections is in action and you are loading
from static lifetime variables, the compiler generates instructions like

lw a5, a_variable
lw a4, b_variable
lw a0, c_variable

When you do not have "-fdata-sections", it uses anchors :

lla a4, .LANCHOR0
lw a5, 0(a4)
lw a3, 4(a4)
lw a0, 8(a4)

From my (limited) understanding, RISC-V cannot use 32-bit absolute addressing. So the "lw a5, a_variable" must be a pseudo-instruction -
using register + offset addressing. If there is a global pointer, then presumably that is used here. Alternatively, the pseudo instruction
might assemble to two real instruction to support the 32-bit address. I
know both techniques are used in some targets, but don't know about RISC-V.

Certainly it would surprise me if the "lw a5, a_variable" version were
more efficient than using anchors - otherwise why would gcc generate
code with anchors when given a free choice? (Perhaps gcc is not well
tuned for RISC-V code generation - I am wary of making too many
assumptions about the processor just from some simple compiler outputs.)

(clang does not, apparently, support section anchors as an optimisation technique. Both with and without -fdata-sections, on RISC-V it first
uses two instructions to load ".L_MergedGlobals" into a register and
then uses that register plus offset to access data.)

I don't tend to think of MSVC as a highly optimising compiler - but it
is not a tool I have much use for, as it does not handle the targets I
need.ÿ When I have sometimes looked at the generated code on godbolt,
it has not impressed me at all.ÿ So it could well fall into the
"helpful when using a weaker compiler" category.

Depends on what target I am building for:
ÿ Windows Native: Typically MSVC
ÿ WSL: Usually GCC or Clang
ÿÿÿ Seems to have: GCC 13.2.0; Clang 18.1.3
ÿÿÿ RISC-V GCC: Also 13.2.0 (also via WSL)
ÿ Linux: Typically GCC

I rarely much use Cygwin anymore, as it was mostly rendered obsolete by
WSL (on Win10 or similar).
Though, Cygwin may still be relevant on Win7 or WinXP systems.

Cygwin has its own wide range of complications. If you want to use gcc targeting native Windows, msys2 and mingw-64 are probably your best bet, either compiled natively under msys2 or as a cross-compile from Linux.
But don't place too much emphasis on my advice, as I very rarely compile
C or C++ code for Windows - most of my PC target (Linux or Windows)
coding is in Python.

For BGBCC, it can build both on native Windows and on Linux/WSL (though recently noted that this build was broken, mostly by GCC and Clang being more pedantic about missing prototypes, and a few prototypes were being missed by my function-prototype mining tool). Went and fixed this, but haven't posted this yet.

As for optimizing in MSVC, yeah, it is in the area of not terrible, but
not super clever either.

If one expects the sort of high-level code-rewriting cleverness that GCC
or Clang often does, one will be disappointed.

But, sometimes, the main "heavy hitter" optimizations are things like constant-folding and register allocation, which it does do effectively.

Though, both MSVC and BGBCC seem to use one sort of strategy for
register allocation:

Static assign things to callee-save registers and use remaining
registers for dynamic allocation within basic-blocks. Variables with
finite non-overlapping lifetimes (that do not cross basic-block
boundaries) may potentially share a register (this more generally
applies to things like temporaries).

And, GCC and Clang use another: Assign dynamically but carry values
across basic-block boundaries along control-flow paths.

Both tend to give different patterns though, and seem to favor different types of code.

[...]

(I could also note that I make heavy use of templates in C++ code - it
often leads to smaller and faster results.)

Curious...

I had tended to use the "write everything one off for the task at hand" approach, but this is a higher-effort approach.

A lot of code tends to fall into the category of shuffling data around
or doing simple checks or conversions. It's also common to have wrapper functions for libraries to get something nicer, safer and more
convenient than some API that belongs in the early 1990's. Good C++
templates (and sometimes even good macros in C) can make the use of
these things far nicer, and most of the code that the templates appear
to generate inline in the caller disappears in optimisation.



--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 31/05/2026 03:37, Janis Papanagnou wrote:

On 2026-05-31 01:43, Keith Thompson wrote:

Bart <bc@freeuk.com> writes:

[...]

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)];

Yes, they can, and I personally tend to agree that they should.

The more complex the expressions are the more structure they need.

IMO, the parenthesis above make precedence clear (if unknown!), but
are not contributing to readability. It would have made more sense
to separate the sub-expression within the [...] in an own object to
enhance readability and to more easily understand what's going on.

To emphasize; not the precedences are the problem above, but the
complexity of the expression in connexion with lack of structuring.

This is an example of how readability depends on the reader. To me,
there is no benefit in having a sub-expression here because the
structure is clear - this is how you do table-based crc's with 4-bit
chunks. But to someone unfamiliar with CRC calculations, splitting the expression up might make it clearer. (Alternatively, a comment block
with an explanation could help.)

I /do/ think the parentheses here are helpful for readability, precisely because they emphasise the structure of the expression. You could write:

crcu32 = crcu32 >> 4 ^ s_crc32[crcu32 & 0xF ^ b & 0xF];

but that needs significantly more cognitive effort to parse when reading
it, could be misinterpreted, and has lost all the structure that makes
it easy to see what is going on.

(I regularly use bit-manipulation and shift instructions in my code -
but I still felt it best to check the details in a precedence table
before writing that.)

The expression as originally parenthesised is thus definitely easier for
/me/ to read, and is almost exactly the way I would write it myself :

crcu32 = (crcu32 >> 4) ^ s_crc32[(crcu32 & 0xF) ^ (b & 0xF)];

The only differences I would have are the names (why would anyone put
variable types into the names like "crcu32" ? We are not writing
BASIC), and I'd use a small case "0xf". Unlike almost every example
Bart has shown before, it even has nice spacing!




--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 31/05/2026 10:12, Richard Harnden wrote:

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.

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.)


--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 31/05/2026 01:29, Lawrence D?Oliveiro wrote:

On Sat, 30 May 2026 12:01:27 +0100, Bart wrote:

It doesn't beed << >> to be in a distinct group from multiply or add
groups.

But it is also not clear because the part after >> is sprawling.

It?s a counterexample to your claim that ?<< >> [don?t need] to be in
a distinct group?, isn?t it?

Sure, when an expression exactly suits how its current level works, such as:

a << b + c

WHEN you intend it to be 'a << (b + c)'. How about when you intend it to
be: '(a << b) + c'?

This is arguably more intuitive since << scales numbers in the same way
as '*'. As it is:

a << 3 + b means a << (3+b)
a * 3 + b means (a*3) + b

And also

a << 3 | b means (a<<3) | b
a << 3 + b means a << (3+b)

Both examples have a similar function but thanks to the odd priorities
are quite different when choosing between << and *, or | and +.


--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 31/05/2026 10:49, David Brown wrote:

On 31/05/2026 10:12, Richard Harnden wrote:

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.

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,

They can do if they make a expression be parsed differently. Do you have
an example where they make no difference but people might think they do?



--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

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 */

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

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 */

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 31/05/2026 12:10, Bart wrote:

On 31/05/2026 10:49, David Brown wrote:

On 31/05/2026 10:12, Richard Harnden wrote:

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.

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,

They can do if they make a expression be parsed differently.

As I said, they "do not affect the generated code unless they affect the semantics of the expression." Obviously that only applies to extra parentheses. If that's what you mean by "parsed differently", then we
agree - clearly "(a + b) * c" gives different code from "a + (b * c)".

But you might consider "(a + b) + c" to be "parsed differently" than "a
+ (b + c)", because of how a particular compiler implements its parser.
It's possible that this results in different code for a particular
compiler, but there is no difference in the meaning for the C language.

I perhaps expressed it poorly when I said extra parentheses "do not"
affect the generated code - extra parentheses do not change the meaning
of the C code, and so compilers don't have to consider them in any way
(and optimising compilers generally don't). But a compiler is, of
course, free to be influenced by them and generate code that varies with
extra parentheses, as long as the final results match those required by
the standard.

Do you have
an example where they make no difference but people might think they do?

People might think they affect the order of evaluation, such as when you
have function calls :

u = foo(x) + (foo(y) + foo(z));

Some people might think the use of parentheses means that "foo(y)" and "foo(z)" are called before "foo(x)", when the order of all these calls
(and the additions) is unspecified. (Again, a given compiler might be influenced by the parentheses, but the language does not require it.)





--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 31/05/2026 02:29, Lawrence D?Oliveiro wrote:

On Sat, 30 May 2026 12:01:27 +0100, Bart wrote:

It doesn't beed << >> to be in a distinct group from multiply or add
groups.

But it is also not clear because the part after >> is sprawling.

It?s a counterexample to your claim that ?<< >> [don?t need] to be in
a distinct group?, isn?t it?

No, it is not. If << and >> had been in the same group as
multiplication and division, your code (the snippets that Bart
referenced) would have had the same semantics. Other code might have different semantics, but Bart was entirely correct in this case.


--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

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.

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 2026-05-31 07:18, David Brown wrote:

On 31/05/2026 12:10, Bart wrote:

On 31/05/2026 10:49, David Brown wrote:

On 31/05/2026 10:12, Richard Harnden wrote:

On 31/05/2026 00:43, Keith Thompson wrote:

...

But you might consider "(a + b) + c" to be "parsed differently" than "a
+ (b + c)", because of how a particular compiler implements its parser.
It's possible that this results in different code for a particular
compiler, but there is no difference in the meaning for the C language.

(a + b) + c mandates adding a to b, then adding the result to c. a + (b
+ c) mandates adding b to c then adding the result to a. As far as
mathematics is concerned, that's the same thing, but in computer math it
can make a difference if one of the two results in overflow or
unnecessary loss of precision, and the other does not.

...

Do you have
an example where they make no difference but people might think they do?

People might think they affect the order of evaluation, such as when you have function calls :

u = foo(x) + (foo(y) + foo(z));

Some people might think the use of parentheses means that "foo(y)" and "foo(z)" are called before "foo(x)", when the order of all these calls
(and the additions) is unspecified. (Again, a given compiler might be influenced by the parentheses, but the language does not require it.

You're correct with regard to the function calls, but the parenthesized addition must be performed first, and the other one second, which may
make a difference, for the same reasons given in my previous paragraph.

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

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).


--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 31/05/2026 16:24, James Kuyper wrote:

On 2026-05-31 07:18, David Brown wrote:

On 31/05/2026 12:10, Bart wrote:

On 31/05/2026 10:49, David Brown wrote:

On 31/05/2026 10:12, Richard Harnden wrote:

On 31/05/2026 00:43, Keith Thompson wrote:

...

But you might consider "(a + b) + c" to be "parsed differently" than "a
+ (b + c)", because of how a particular compiler implements its parser.
It's possible that this results in different code for a particular
compiler, but there is no difference in the meaning for the C language.

(a + b) + c mandates adding a to b, then adding the result to c. a + (b
+ c) mandates adding b to c then adding the result to a. As far as mathematics is concerned, that's the same thing, but in computer math it
can make a difference if one of the two results in overflow or
unnecessary loss of precision, and the other does not.

...

Do you have
an example where they make no difference but people might think they do? >>>

People might think they affect the order of evaluation, such as when you
have function calls :

u = foo(x) + (foo(y) + foo(z));

Some people might think the use of parentheses means that "foo(y)" and
"foo(z)" are called before "foo(x)", when the order of all these calls
(and the additions) is unspecified. (Again, a given compiler might be
influenced by the parentheses, but the language does not require it.

You're correct with regard to the function calls, but the parenthesized addition must be performed first, and the other one second, which may
make a difference, for the same reasons given in my previous paragraph.

The parentheses do not dictate the order of evaluation. But you are
correct - and it's worth pointing out, so thank you for doing that -
that for floating point operations, the grouping of operations can
affect the result.

If you are talking about floating point arithmetic (I was thinking of
integer arithmetic, but did not specify), then the operations are not necessarily commutative or associative, and the compiler cannot then re-arrange the operations unless it knows that doing so does not affect
the result.

But except for specific cases, the order of evaluation - both for the
values and side-effects - of sub-expressions is unspecified. Indeed,
they are unsequenced - the evaluations can interleave.

Usually, both sub-expressions of a binary operator will be evaluated
before the operator itself, simply because usually the results of the
operator cannot be calculated until the sub-expression's values are
known. But this is not a requirement of the language - if the compiler
can get the same results without doing so, it is free to pick a
different order. "(a + b) * 0" does not need to evaluate "a", "b", or
"a + b" at all unless there is a possibility of a side-effect - and it
can perform the side-effects in any order. "a + (b + c)" can check "a"
for a trap representation and deal with that before looking at "b" and
"c" or the results of "b + c", even though it cannot (for floating point operations) re-arrange the code to do "a + b" first.

If an implementation provides additional semantics to signed integer arithmetic, such as saturating or trapping overflow, then signed integer arithmetic operations are no longer associative. But normal C undefined behaviour on overflow is fully associative (as is wrapping semantics,
for addition, subtraction and multiplication).

So for non-associative operations, parentheses can affect the semantics
- and therefore the most likely (but not required) order of evaluation
of at least some parts of the sub-expressions. However, that also then
means we are not longer talking about parentheses that do not affect the semantics of the expression, which is what this thread branch is about.



--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

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.

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 2026-05-31 11:35, David Brown wrote:
...

Usually, both sub-expressions of a binary operator will be evaluated
before the operator itself, simply because usually the results of the operator cannot be calculated until the sub-expression's values are
known. But this is not a requirement of the language

"The value computations of the operands of an operator are sequenced
before the value computation of the result of the operator." (6.5.1p3)

- if the compiler

can get the same results without doing so, it is free to pick a
different order.

Correct - but "same results" is crucial; it allows you to invoke the
"as-if" rule. Otherwise, the sequencing specified by 6.5.1p3 must be
honored.

...

If an implementation provides additional semantics to signed integer arithmetic, such as saturating or trapping overflow, then signed integer arithmetic operations are no longer associative. But normal C undefined behaviour on overflow is fully associative (as is wrapping semantics,
for addition, subtraction and multiplication).

I don't follow that. I believe that overflow is guaranteed for (5 +
INT_MAX) + INT_MIN, and completely avoided by 5 + (INT_MAX + INT_MIN),
which differ only by association. Are you saying they both have the
same chance of overflowing?

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

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.


--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 5/31/2026 4:14 AM, David Brown wrote:

On 30/05/2026 22:48, BGB wrote:

On 5/30/2026 6:52 AM, David Brown wrote:

On 29/05/2026 22:16, BGB wrote:

On 5/29/2026 6:22 AM, David Brown wrote:

On 29/05/2026 12:20, BGB wrote:

On 5/29/2026 2:52 AM, Janis Papanagnou wrote:

On 2026-05-28 11:57, BGB wrote:

On 5/28/2026 2:18 AM, Janis Papanagnou wrote:

On 2026-05-28 01:49, BGB wrote:

[...]

But, not really an "easy" way to avoid bloat, other than to
write code specifically for what cases are relevant; while also >>>>>>>> avoiding needless duplication and copy paste (where, overuse of >>>>>>>> copy/paste can also lead to bloat; along with turning the code >>>>>>>> into an ugly mess).

Hmm.. - as said, the during very early days there were issues; I >>>>>>> recall on one platform duplication of template code in more that >>>>>>> one source unit. And/or some environmental hacks (of the compiler) >>>>>>> to deposit template code for linking. In the later days I've not >>>>>>> seen such immature things anymore.

Possibly, a lot could depend on how one is counting things as well. >>>>>>

In a lot of cases when using GCC, I end up using:
ÿÿ -ffunction-sections -fdata-sections -Wl,-gc-sections

On many targets, "-fdata-sections" can lead to noticeably larger
and slower code because it effectively eliminates section anchor
optimisations.ÿ It does not negatively affect x86 AFAICS, because
x86 does not use section anchors.

<https://godbolt.org/z/zeoq41Y7d>

With -fsection-anchors (enabled with optimisation on targets that
support it - generally RISCy load/store architectures), program-
lifetime variables are kept together in a lump (as though they were >>>>> in a struct) and often addressed by a pointer to that pretend
struct. Thus if a function accesses two variables "a" and "b",
instead of having to load the addresses of each of "a" and "b" into >>>>> separate registers, it loads an "anchor" into one register and
accesses the variables with reg+offset addressing.

I've seen "-fdata-sections" used regularly in embedded systems - it >>>>> is almost always a bad idea.

("-ffunction-sections" is often very helpful to reduce code image
size, so keep that one.)

Both seem to help on x86, x86-64, and also on RISC-V, at making
GCC's output at least sorta space-comparable to my own compilers.

The merit of "-fdata-sections" is mostly that it eliminates unused
global variables; whereas "-ffunction-sections" eliminates
unreachable functions.

That is the point of them, yes.ÿ "-ffunction-sections" can be useful
at removing unused code from more general code.ÿ For
microcontrollers, SDK's and manufacturers' driver code will normally
contain a large number of functions that can be eliminated in this
way, saving a lot of code space.

However, in practice, "-fdata-sections" rarely eliminates a
significant amount - most programs do not have large amounts of
statically-allocated data that is not used.ÿ Gcc, and I think most
other compilers, put the static lifetime data for each translation
unit in its own section, so if no data from a translation unit is
used it will be eliminated at link time even with -fno-data-
sections.ÿ And of course it makes no difference for heap data or
stack data.

The main place it makes a difference is global arrays from a
translation unit that is included, but for functions that are not
included.

Also functions with large static arrays.


void SomeFunc()
{
ÿÿ static char buf[4096];
ÿÿ ...
}

Where, say, eliminating SomeFunc does not necessarily eliminate buf.

Yes, if you have such code but want to eliminate it, then -fdata-
sections would definitely benefit.ÿ I have not seen such code in
practice (at least not with very big static arrays, and that also was
not an essential part of the program).ÿ But of course I have only seen a microscopic part of all C code written - if you come across this sort of thing, then I appreciate your point.

(There are several ways to make this more "friendly" to builds that need
to be compact, such as putting the buffer and/or SomeFunc in a separate
file or giving it a specific section of its own.)

I have seen this pattern sometimes, though usually in "medium old" code,
with newer code more often assuming that the stack is really big and so
can handle putting 1MB or more in a local array. Though, this is not
great on a target which doesn't have a huge stack.

In my case, I usually had 128K as the default stack size in my project.

In my testing, "-ffunction-sections" is absolutely worth using (on
targets where code space is relevant - there's no need for PC
software). ÿÿOn some targets, it may mean a few lost opportunities
for shorter jump/call instructions between functions in the same
translation unit, but the cost is rarely anything more than a
slightly longer link time. But "-fdata-sections" typically gives
almost no ram space savings, and makes code bigger and slower.

As I noted, gcc on x86 does not support section anchors, so there is
not likely to be much code cost for -ffdata-sections.

Where section anchors shine - and where -fdata-sections therefore has
cost - is when a function needs to access more than one piece of
static lifetime data defined in the same translation unit (or another
translation unit if you are using LTO).ÿ That happens a lot in
embedded ARM programming at least.ÿ I don't know about RISC-V.ÿ If
the target normally uses a "small data section" for ram (I know this
is common on PowerPC), then there is, in effect, a program-wide
section anchor already.ÿ So it is possible that it relatively few
targets have section anchors - but the 32-bit ARM on gcc is a vastly
popular choice in the embedded world, so it is important to
understand the cost of this compiler flag for that target at least.

It depends on the way it is built.


A lot of times though (for non-relocatable static-linked binaries) it
mostly tends to use AUIPC+LD or AUIPC+ST pairs to access global
variables. There is a Global Pointer that needs to be loaded when the
binary is started, unclear what it is used for exactly.

If you have a global pointer, then it will probably be used for
gp+offset access to global data, eliminating the need for section anchors.

I have not used RISC-V, and am not familiar with its details.ÿ I can see from godbolt that when -fdata-sections is in action and you are loading
from static lifetime variables, the compiler generates instructions like

ÿÿÿÿlw a5, a_variable
ÿÿÿÿlw a4, b_variable
ÿÿÿÿlw a0, c_variable

When you do not have "-fdata-sections", it uses anchors :

ÿÿÿÿlla a4, .LANCHOR0
ÿÿÿÿlw a5, 0(a4)
ÿÿÿÿlw a3, 4(a4)
ÿÿÿÿlw a0, 8(a4)

From my (limited) understanding, RISC-V cannot use 32-bit absolute addressing.ÿ So the "lw a5, a_variable" must be a pseudo-instruction -
using register + offset addressing.ÿ If there is a global pointer, then presumably that is used here.ÿ Alternatively, the pseudo instruction
might assemble to two real instruction to support the 32-bit address.ÿ I know both techniques are used in some targets, but don't know about RISC-V.

It can use one of two strategies for these (after breaking up pseudo-instructions):
LUI a5, HiAddr //Abs32, Low 2GB only
LW a5, LoAddr(a5)
Or:
AUIPC a5, HiAddr //PC-Rel
LW a5, LoAddr(a5)

IIRC, LLA is similar, just using an ADDI as the second instruction.
But, yeah, the latter sequence would be more efficient.


I would expect something different if building with -fPIC or -fPIE, but
this depends on if it is a version of GCC built with support for these
(if using a version of GCC built for non-hosted targets, it ignores
these). Where, one effectively needs different GCC builds for bare-metal
(like OS kernels) and for hosted Linux development, for whatever bizarre reason...

Certainly it would surprise me if the "lw a5, a_variable" version were
more efficient than using anchors - otherwise why would gcc generate
code with anchors when given a free choice?ÿ (Perhaps gcc is not well
tuned for RISC-V code generation - I am wary of making too many
assumptions about the processor just from some simple compiler outputs.)

It is not, it is a 2-op sequence usually.

Plain RISC-V has a bigger problem with 64-bit constants though,
generally needs to either load these from memory (more typical in GCC)
or build them in-place (which needs roughly 6 instructions in RISC-V).

Say (possible, but GCC doesn't do this):
LUI t0, ValHiA
LUI t1, valHiB
ADDI t0, t0, valLoA
ADDI t1, t1, valLoB
SLLI t1, t1, 32
ADD a0, t0, t1


In my case, I have extensions for RV that can turn a lot of this stuff
into single instructions (albeit with larger 8 and 12 byte encodings).

In some cases, it can save bytes, for example:
LW a1, Disp33s(a0)
As a 64-bit / 8-byte encoding, vs:
LUI t0, DispHi
ADD t0, t0, a0
LW a1, DispLo(a0)
Needing 12 bytes.


My own (more drastic) extensions can save more, by having a few Disp16 instructions, which can access 256K or 512K past GP within a single
32-bit instruction.


But, if/when any of this would end up in mainline RISC-V is uncertain.
Weirdly, there is a lot more emphasis there on big/fancy features (with
niche applicability), rather than on smaller things that can improve the properties of the base ISA (and that could more generally benefit nearly
all code built for the ISA).

(clang does not, apparently, support section anchors as an optimisation technique.ÿ Both with and without -fdata-sections, on RISC-V it first
uses two instructions to load ".L_MergedGlobals" into a register and
then uses that register plus offset to access data.)

Yeah.

As noted, BGBCC mostly use the GP register to access globals for RV
based targets; sorting them out so that the most common ones come first
and so are typically a single instruction.

This is one merit though of not using separate compilation.
However, the approach used by my compiler is much more memory intensive.

I don't tend to think of MSVC as a highly optimising compiler - but
it is not a tool I have much use for, as it does not handle the
targets I need.ÿ When I have sometimes looked at the generated code
on godbolt, it has not impressed me at all.ÿ So it could well fall
into the "helpful when using a weaker compiler" category.

Depends on what target I am building for:
ÿÿ Windows Native: Typically MSVC
ÿÿ WSL: Usually GCC or Clang
ÿÿÿÿ Seems to have: GCC 13.2.0; Clang 18.1.3
ÿÿÿÿ RISC-V GCC: Also 13.2.0 (also via WSL)
ÿÿ Linux: Typically GCC

I rarely much use Cygwin anymore, as it was mostly rendered obsolete
by WSL (on Win10 or similar).
Though, Cygwin may still be relevant on Win7 or WinXP systems.

Cygwin has its own wide range of complications.ÿ If you want to use gcc targeting native Windows, msys2 and mingw-64 are probably your best bet, either compiled natively under msys2 or as a cross-compile from Linux.
But don't place too much emphasis on my advice, as I very rarely compile
C or C++ code for Windows - most of my PC target (Linux or Windows)
coding is in Python.

Yes, I had used MinGW for a while, before mostly moving over to MSVC for native Windows.

The tradeoff is mostly:
MinGW is closer to native for Windows;
Cygwin could give a closer approximation of Linux on Windows, so one can
build a lot of Linux software and use "./configure" scripts and similar.


But, as noted, Cygwin's role was mostly displaced by WSL, which
effectively runs a Linux userland on Windows.


There was WSL1, which basically mapped Linux syscalls over to the
Windows kernel, and WSL2, which runs the Linux kernel in a VM.


Though, in my case I was using WSL1 as seemingly MS had decided that my
PC can't do virtualization (and sees it as necessary for WSL2), even
despite having a CPU that can do so, and it is enabled in the BIOS.

For BGBCC, it can build both on native Windows and on Linux/WSL
(though recently noted that this build was broken, mostly by GCC and
Clang being more pedantic about missing prototypes, and a few
prototypes were being missed by my function-prototype mining tool).
Went and fixed this, but haven't posted this yet.


As for optimizing in MSVC, yeah, it is in the area of not terrible,
but not super clever either.

If one expects the sort of high-level code-rewriting cleverness that
GCC or Clang often does, one will be disappointed.

But, sometimes, the main "heavy hitter" optimizations are things like
constant-folding and register allocation, which it does do effectively.

Though, both MSVC and BGBCC seem to use one sort of strategy for
register allocation:


Static assign things to callee-save registers and use remaining
registers for dynamic allocation within basic-blocks. Variables with
finite non-overlapping lifetimes (that do not cross basic-block
boundaries) may potentially share a register (this more generally
applies to things like temporaries).

And, GCC and Clang use another: Assign dynamically but carry values
across basic-block boundaries along control-flow paths.

Both tend to give different patterns though, and seem to favor
different types of code.

[...]

(I could also note that I make heavy use of templates in C++ code -
it often leads to smaller and faster results.)

Curious...


I had tended to use the "write everything one off for the task at
hand" approach, but this is a higher-effort approach.

A lot of code tends to fall into the category of shuffling data around
or doing simple checks or conversions.ÿ It's also common to have wrapper functions for libraries to get something nicer, safer and more
convenient than some API that belongs in the early 1990's.ÿ Good C++ templates (and sometimes even good macros in C) can make the use of
these things far nicer, and most of the code that the templates appear
to generate inline in the caller disappears in optimisation.

OK.



--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

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.


--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

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.


--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 31/05/2026 20:25, BGB wrote:

On 5/31/2026 4:14 AM, David Brown wrote:

On 30/05/2026 22:48, BGB wrote:

On 5/30/2026 6:52 AM, David Brown wrote:

On 29/05/2026 22:16, BGB wrote:

On 5/29/2026 6:22 AM, David Brown wrote:

On 29/05/2026 12:20, BGB wrote:

On 5/29/2026 2:52 AM, Janis Papanagnou wrote:

On 2026-05-28 11:57, BGB wrote:

On 5/28/2026 2:18 AM, Janis Papanagnou wrote:

On 2026-05-28 01:49, BGB wrote:

[...]

Also functions with large static arrays.


void SomeFunc()
{
ÿÿ static char buf[4096];
ÿÿ ...
}

Where, say, eliminating SomeFunc does not necessarily eliminate buf.

Yes, if you have such code but want to eliminate it, then -fdata-
sections would definitely benefit.ÿ I have not seen such code in
practice (at least not with very big static arrays, and that also was
not an essential part of the program).ÿ But of course I have only seen
a microscopic part of all C code written - if you come across this
sort of thing, then I appreciate your point.

(There are several ways to make this more "friendly" to builds that
need to be compact, such as putting the buffer and/or SomeFunc in a
separate file or giving it a specific section of its own.)

I have seen this pattern sometimes, though usually in "medium old" code, with newer code more often assuming that the stack is really big and so
can handle putting 1MB or more in a local array. Though, this is not
great on a target which doesn't have a huge stack.

In my case, I usually had 128K as the default stack size in my project.

OK. My code typically has a stack of 1 KB or less per thread. It is
not inconceivable that I would have a static array like this, but it
would not be in code that is likely to be unused.

Where section anchors shine - and where -fdata-sections therefore
has cost - is when a function needs to access more than one piece of
static lifetime data defined in the same translation unit (or
another translation unit if you are using LTO).ÿ That happens a lot
in embedded ARM programming at least.ÿ I don't know about RISC-V.
If the target normally uses a "small data section" for ram (I know
this is common on PowerPC), then there is, in effect, a program-wide
section anchor already.ÿ So it is possible that it relatively few
targets have section anchors - but the 32-bit ARM on gcc is a vastly
popular choice in the embedded world, so it is important to
understand the cost of this compiler flag for that target at least.

It depends on the way it is built.


A lot of times though (for non-relocatable static-linked binaries) it
mostly tends to use AUIPC+LD or AUIPC+ST pairs to access global
variables. There is a Global Pointer that needs to be loaded when the
binary is started, unclear what it is used for exactly.

If you have a global pointer, then it will probably be used for
gp+offset access to global data, eliminating the need for section
anchors.

I have not used RISC-V, and am not familiar with its details.ÿ I can
see from godbolt that when -fdata-sections is in action and you are
loading from static lifetime variables, the compiler generates
instructions like

ÿÿÿÿÿlw a5, a_variable
ÿÿÿÿÿlw a4, b_variable
ÿÿÿÿÿlw a0, c_variable

When you do not have "-fdata-sections", it uses anchors :

ÿÿÿÿÿlla a4, .LANCHOR0
ÿÿÿÿÿlw a5, 0(a4)
ÿÿÿÿÿlw a3, 4(a4)
ÿÿÿÿÿlw a0, 8(a4)

ÿFrom my (limited) understanding, RISC-V cannot use 32-bit absolute
addressing.ÿ So the "lw a5, a_variable" must be a pseudo-instruction -
using register + offset addressing.ÿ If there is a global pointer,
then presumably that is used here.ÿ Alternatively, the pseudo
instruction might assemble to two real instruction to support the 32-
bit address.ÿ I know both techniques are used in some targets, but
don't know about RISC-V.

It can use one of two strategies for these (after breaking up pseudo- instructions):
ÿ LUIÿÿÿ a5, HiAddrÿÿÿÿÿ //Abs32, Low 2GB only
ÿ LWÿÿÿÿ a5, LoAddr(a5)
Or:
ÿ AUIPCÿ a5, HiAddrÿÿÿÿÿ //PC-Rel
ÿ LWÿÿÿÿ a5, LoAddr(a5)

IIRC, LLA is similar, just using an ADDI as the second instruction.
But, yeah, the latter sequence would be more efficient.

Thanks. That clears things up for me. And in particular, it shows that section anchors (and therefore no "-fdata-sections") can make a
significant difference to gcc code for RISC-V.

I would expect something different if building with -fPIC or -fPIE, but
this depends on if it is a version of GCC built with support for these
(if using a version of GCC built for non-hosted targets, it ignores
these). Where, one effectively needs different GCC builds for bare-metal (like OS kernels) and for hosted Linux development, for whatever bizarre reason...

Certainly it would surprise me if the "lw a5, a_variable" version were
more efficient than using anchors - otherwise why would gcc generate
code with anchors when given a free choice?ÿ (Perhaps gcc is not well
tuned for RISC-V code generation - I am wary of making too many
assumptions about the processor just from some simple compiler outputs.)

It is not, it is a 2-op sequence usually.

Plain RISC-V has a bigger problem with 64-bit constants though,
generally needs to either load these from memory (more typical in GCC)
or build them in-place (which needs roughly 6 instructions in RISC-V).

Say (possible, but GCC doesn't do this):
ÿ LUIÿÿ t0, ValHiA
ÿ LUIÿÿ t1, valHiB
ÿ ADDIÿ t0, t0, valLoA
ÿ ADDIÿ t1, t1, valLoB
ÿ SLLIÿ t1, t1, 32
ÿ ADDÿÿ a0, t0, t1

In my case, I have extensions for RV that can turn a lot of this stuff
into single instructions (albeit with larger 8 and 12 byte encodings).

In some cases, it can save bytes, for example:
ÿ LWÿÿ a1, Disp33s(a0)
As a 64-bit / 8-byte encoding, vs:
ÿ LUIÿ t0, DispHi
ÿ ADDÿ t0, t0, a0
ÿ LWÿÿ a1, DispLo(a0)
Needing 12 bytes.

My own (more drastic) extensions can save more, by having a few Disp16 instructions, which can access 256K or 512K past GP within a single 32-
bit instruction.

But, if/when any of this would end up in mainline RISC-V is uncertain. Weirdly, there is a lot more emphasis there on big/fancy features (with niche applicability), rather than on smaller things that can improve the properties of the base ISA (and that could more generally benefit nearly
all code built for the ISA).

[...]

Cygwin has its own wide range of complications.ÿ If you want to use
gcc targeting native Windows, msys2 and mingw-64 are probably your
best bet, either compiled natively under msys2 or as a cross-compile
from Linux. But don't place too much emphasis on my advice, as I very
rarely compile C or C++ code for Windows - most of my PC target (Linux
or Windows) coding is in Python.

Yes, I had used MinGW for a while, before mostly moving over to MSVC for native Windows.

The tradeoff is mostly:
MinGW is closer to native for Windows;
Cygwin could give a closer approximation of Linux on Windows, so one can build a lot of Linux software and use "./configure" scripts and similar.

Note that MinGW and Mingw-w64 are very, very different. (And the corresponding environments and utility collections, msys and msys2, are equally different.) Mingw-w64, as I understand it, is somewhat of a
balance between old MinGW and Cygwin in being close to native for most purposes, but providing more POSIX compliance than MinGW. It is also
much newer, much better maintained, with modern language support in its
tools (last I heard, with MinGW you did not even get C99 support in the standard library). And of course it has 64-bit support.

You may well find WSL or MSVC to be a better choice for your
requirements, but don't mistake Mingw-w64 for MinGW.

But, as noted, Cygwin's role was mostly displaced by WSL, which
effectively runs a Linux userland on Windows.

There was WSL1, which basically mapped Linux syscalls over to the
Windows kernel, and WSL2, which runs the Linux kernel in a VM.

Though, in my case I was using WSL1 as seemingly MS had decided that my
PC can't do virtualization (and sees it as necessary for WSL2), even
despite having a CPU that can do so, and it is enabled in the BIOS.

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 31/05/2026 18:46, James Kuyper wrote:

On 2026-05-31 11:35, David Brown wrote:
...

Usually, both sub-expressions of a binary operator will be evaluated
before the operator itself, simply because usually the results of the
operator cannot be calculated until the sub-expression's values are
known. But this is not a requirement of the language

"The value computations of the operands of an operator are sequenced
before the value computation of the result of the operator." (6.5.1p3)

- if the compiler

can get the same results without doing so, it is free to pick a
different order.

Correct - but "same results" is crucial; it allows you to invoke the
"as-if" rule. Otherwise, the sequencing specified by 6.5.1p3 must be
honored.

OK.

...

If an implementation provides additional semantics to signed integer
arithmetic, such as saturating or trapping overflow, then signed integer
arithmetic operations are no longer associative. But normal C undefined
behaviour on overflow is fully associative (as is wrapping semantics,
for addition, subtraction and multiplication).

I don't follow that. I believe that overflow is guaranteed for (5 +
INT_MAX) + INT_MIN, and completely avoided by 5 + (INT_MAX + INT_MIN),
which differ only by association. Are you saying they both have the
same chance of overflowing?

No - I see now what you are saying. Overflow is never guaranteed to do anything, including to exist, because it is UB. So the compiler can
happily treat "(5 + INT_MAX) + INT_MIN" as though you had written "5 + (INT_MAX + INT_MIN)". It can freely re-arrange an expression like this
that has a potential overflow into one without risk of overflow, as long
as the same results are given for all values that do not overflow. (The overflow is not part of the observable behaviour.) But it cannot
re-arrange the other way unless it knows that intermediary overflows
have no effect. (And the compiler usually does know this.)

What I am trying to say - but described inaccurately - is that
expressions can be re-arranged by the compiler without preserving
overflow behaviour, but it must avoid introducing /new/ overflow risks
if they can affect the results. It may, however, introduce new
intermediary overflows if they do not affect the results.




--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 2026-05-31 16:24, David Brown wrote:

On 31/05/2026 18:46, James Kuyper wrote:

On 2026-05-31 11:35, David Brown wrote:

...

If an implementation provides additional semantics to signed integer
arithmetic, such as saturating or trapping overflow, then signed integer >>> arithmetic operations are no longer associative. But normal C undefined >>> behaviour on overflow is fully associative (as is wrapping semantics,
for addition, subtraction and multiplication).

I don't follow that. I believe that overflow is guaranteed for (5 +
INT_MAX) + INT_MIN, and completely avoided by 5 + (INT_MAX + INT_MIN),
which differ only by association. Are you saying they both have the
same chance of overflowing?

No - I see now what you are saying. Overflow is never guaranteed to do anything, including to exist, because it is UB. So the compiler can

I only meant that overflow was guaranteed, and that the behavior was
therefore guaranteed to be undefined. I didn't mean to imply that any particular behavior was guaranteed.

happily treat "(5 + INT_MAX) + INT_MIN" as though you had written "5 + (INT_MAX + INT_MIN)". It can freely re-arrange an expression like this
that has a potential overflow into one without risk of overflow, as long
as the same results are given for all values that do not overflow. (The overflow is not part of the observable behaviour.) But it cannot
re-arrange the other way unless it knows that intermediary overflows
have no effect. (And the compiler usually does know this.)

That's what I was mainly concerned about - if I've carefully arranged to
make sure that overflow is impossible, I'd be rather upset by a compiler
which, because "normal C undefined behaviour on overflow is fully
associative", rearranges the associations in my code to make overflow
possible. I interpreted that comment as meaning that "whether or not the behavior is undefined is fully associative". I guess that what you
actually meant was "if the behavior is undefined, the compiler is free
to rearrange the associations".

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

David Brown <david.brown@hesbynett.no> writes:

On 31/05/2026 16:24, James Kuyper wrote:

On 2026-05-31 07:18, David Brown wrote:

[...]

People might think they affect the order of evaluation, such as when you >>> have function calls :

u = foo(x) + (foo(y) + foo(z));

Some people might think the use of parentheses means that "foo(y)" and
"foo(z)" are called before "foo(x)", when the order of all these calls
(and the additions) is unspecified. (Again, a given compiler might be
influenced by the parentheses, but the language does not require it.

You're correct with regard to the function calls, but the
parenthesized addition must be performed first, and the other one
second, which may make a difference, for the same reasons given in my
previous paragraph.

The parentheses do not dictate the order of evaluation. But you are
correct - and it's worth pointing out, so thank you for doing that -
that for floating point operations, the grouping of operations can
affect the result.

The parentheses do not dictate the order of evaluation *of the
operands*. Each "+" can be evaluated (the addition performed)
only after the values of its operands are known. But regardless
of parentheses or operator precedence, the three operands foo(x),
foo(y), and foo(z) can be evaluated in any of 6 possible orders.
(It's different when you have operations like "&&", "||", and ",",
which imposes additional sequence points.)

If you are talking about floating point arithmetic (I was thinking of
integer arithmetic, but did not specify), then the operations are not necessarily commutative or associative, and the compiler cannot then re-arrange the operations unless it knows that doing so does not
affect the result.

It's not just floating-point. Signed integer overflow is also relevant.

(INT_MIN + INT_MAX) + 1 is well defined. (INT_MIN + INT_MAX) +1
is equivalent, and is also well defined. INT_MIN + (INT_MAX +1)
has undefined behavior.

But except for specific cases, the order of evaluation - both for the
values and side-effects - of sub-expressions is unspecified. Indeed,
they are unsequenced - the evaluations can interleave.

Usually, both sub-expressions of a binary operator will be evaluated
before the operator itself, simply because usually the results of the operator cannot be calculated until the sub-expression's values are
known. But this is not a requirement of the language - if the
compiler can get the same results without doing so, it is free to pick
a different order. "(a + b) * 0" does not need to evaluate "a", "b",
or "a + b" at all unless there is a possibility of a side-effect - and
it can perform the side-effects in any order. "a + (b + c)" can check
"a" for a trap representation and deal with that before looking at "b"
and "c" or the results of "b + c", even though it cannot (for floating
point operations) re-arrange the code to do "a + b" first.

Yes, a compiler can reduce (a + b) * 0 to just 0. But it's not
required to do so, and (INT_MAX + 1) * 0 still has undefined
behavior. Undefined behavior is determined by the rules of the
abstract machine *without* any adjustments permitted by the as-if
rule.

[...]

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

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.

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

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 */

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

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.

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Sun, 31 May 2026 10:59:42 +0100, Bart wrote:

How about when you intend it to be: '(a << b) + c'?

I gave real-world examples of the usage that you asked for, how about
you do the same?

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 01/06/2026 01:33, Lawrence D?Oliveiro wrote:

On Sun, 31 May 2026 10:59:42 +0100, Bart wrote:

How about when you intend it to be: '(a << b) + c'?

I gave real-world examples of the usage that you asked for, how about
you do the same?

Can do, but they wouldn't be in C. The problems are when I port to C or
port from C or simply try to understand it.

Examples:

hsum := hsum << 4 - hsum + c

lxvalue := lxvalue << 8 + (pstart+i-1)^

macro makemodrm(mode, opc, rm) = mode<<6 + opc<<3 + rm

genxrm(0xD9 + mf << 1, code, a)

am.sib := scaletable[scale]<<6 + index<<3 + base

p++^ := r>>5<<5 + g>>5<<2 + b>>6

scale := (sib>>6 + 1| 1, 2, 4, 8 |0)

hdr.usedc[i+1] := t>>4 + 1

index := r<<5 + g<<2 + b

rgb := b<<16 + g<<8 + r

shortopc := ttt<<3 + rmopc

Here, '<< >>' have same precedence as '* /'.

Notice I like to use '+' rather than '|', which in my syntax is 'ior'.
But '+ -' and 'iand ior ixor' all have the same precedence so I'd never
have to worry about it anyway

In C, '+ -' and '& | ^' are on opposite sides of '<< >>'.

And yes sometime I need to use parentheses to override; it is no big deal.

Generally, C seems to need at least 20% more parentheses (as a
proportion of all tokens) than code written in my syntax despite all
these extra levels to help you write fewer.

Bear in mind that C uses {...} to enclose data where I'd need to use
(...), but those {} aren't counted.


--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

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.

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 01/06/2026 00:26, James Kuyper wrote:

On 2026-05-31 16:24, David Brown wrote:

On 31/05/2026 18:46, James Kuyper wrote:

On 2026-05-31 11:35, David Brown wrote:

...

If an implementation provides additional semantics to signed integer
arithmetic, such as saturating or trapping overflow, then signed integer >>>> arithmetic operations are no longer associative. But normal C undefined >>>> behaviour on overflow is fully associative (as is wrapping semantics,
for addition, subtraction and multiplication).

I don't follow that. I believe that overflow is guaranteed for (5 +
INT_MAX) + INT_MIN, and completely avoided by 5 + (INT_MAX + INT_MIN),
which differ only by association. Are you saying they both have the
same chance of overflowing?

No - I see now what you are saying. Overflow is never guaranteed to do
anything, including to exist, because it is UB. So the compiler can

I only meant that overflow was guaranteed, and that the behavior was therefore guaranteed to be undefined. I didn't mean to imply that any particular behavior was guaranteed.

That's a useful distinction.

happily treat "(5 + INT_MAX) + INT_MIN" as though you had written "5 +
(INT_MAX + INT_MIN)". It can freely re-arrange an expression like this
that has a potential overflow into one without risk of overflow, as long
as the same results are given for all values that do not overflow. (The
overflow is not part of the observable behaviour.) But it cannot
re-arrange the other way unless it knows that intermediary overflows
have no effect. (And the compiler usually does know this.)

That's what I was mainly concerned about - if I've carefully arranged to
make sure that overflow is impossible, I'd be rather upset by a compiler which, because "normal C undefined behaviour on overflow is fully associative", rearranges the associations in my code to make overflow possible.

I am quite happy for the compiler to make such re-arrangements, as long
as it knows that doing so gives the same results on the target. I too
would be most upset if it made these re-arrangements when I had the flag "-fsanitize=signed-overflow" (or equivalent on other compilers) in
action and halted my program when it "discovered" and overflow bug. But
I am quite happy for it to make these re-arrangements for the code it generates - I am always happy with more efficient object code that
follows the "as if" rule.

(If the expression is floating point, or the target has unusual
capabilities, so that an overflow is detectable then of course such re-arrangements are not valid as they would break the "as-if" rule.)

I interpreted that comment as meaning that "whether or not the
behavior is undefined is fully associative". I guess that what you
actually meant was "if the behavior is undefined, the compiler is free
to rearrange the associations".

That is better phrasing than I used. Thanks.



--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 01/06/2026 00:54, Keith Thompson wrote:

David Brown <david.brown@hesbynett.no> writes:

On 31/05/2026 16:24, James Kuyper wrote:

On 2026-05-31 07:18, David Brown wrote:

[...]

People might think they affect the order of evaluation, such as when you >>>> have function calls :

u = foo(x) + (foo(y) + foo(z));

Some people might think the use of parentheses means that "foo(y)" and >>>> "foo(z)" are called before "foo(x)", when the order of all these calls >>>> (and the additions) is unspecified. (Again, a given compiler might be >>>> influenced by the parentheses, but the language does not require it.

You're correct with regard to the function calls, but the
parenthesized addition must be performed first, and the other one
second, which may make a difference, for the same reasons given in my
previous paragraph.

The parentheses do not dictate the order of evaluation. But you are
correct - and it's worth pointing out, so thank you for doing that -
that for floating point operations, the grouping of operations can
affect the result.

The parentheses do not dictate the order of evaluation *of the
operands*. Each "+" can be evaluated (the addition performed)
only after the values of its operands are known. But regardless
of parentheses or operator precedence, the three operands foo(x),
foo(y), and foo(z) can be evaluated in any of 6 possible orders.
(It's different when you have operations like "&&", "||", and ",",
which imposes additional sequence points.)

Yes. And I have seen code where the author believed that the
parentheses /did/ affect the order of evaluation of the "foo" calls. It
is definitely a misunderstanding people can make, though I of course
have no idea how often people make it.

If you are talking about floating point arithmetic (I was thinking of
integer arithmetic, but did not specify), then the operations are not
necessarily commutative or associative, and the compiler cannot then
re-arrange the operations unless it knows that doing so does not
affect the result.

It's not just floating-point. Signed integer overflow is also relevant.

(INT_MIN + INT_MAX) + 1 is well defined. (INT_MIN + INT_MAX) +1
is equivalent, and is also well defined. INT_MIN + (INT_MAX +1)
has undefined behavior.

Compilers can re-arrange integer arithmetic, despite new overflows, if
they know the result is the same. On pretty much any current processor,
a compiler generating code for integer "a + b + c" could do the
additions in any order - treating the operations as commutative and
fully associative. The final result will be the same in every case
where the original expression did not overflow (i.e., every case with
defined behaviour).

If the implementation makes overflow detectable in some way (such as by "-fsanitize=signed-arithmetic-overflow"), or the hardware does something
that gives different results from overflow (saturating, hardware traps),
then it's an entirely different matter.

But except for specific cases, the order of evaluation - both for the
values and side-effects - of sub-expressions is unspecified. Indeed,
they are unsequenced - the evaluations can interleave.

Usually, both sub-expressions of a binary operator will be evaluated
before the operator itself, simply because usually the results of the
operator cannot be calculated until the sub-expression's values are
known. But this is not a requirement of the language - if the
compiler can get the same results without doing so, it is free to pick
a different order. "(a + b) * 0" does not need to evaluate "a", "b",
or "a + b" at all unless there is a possibility of a side-effect - and
it can perform the side-effects in any order. "a + (b + c)" can check
"a" for a trap representation and deal with that before looking at "b"
and "c" or the results of "b + c", even though it cannot (for floating
point operations) re-arrange the code to do "a + b" first.

Yes, a compiler can reduce (a + b) * 0 to just 0. But it's not
required to do so, and (INT_MAX + 1) * 0 still has undefined
behavior. Undefined behavior is determined by the rules of the
abstract machine *without* any adjustments permitted by the as-if
rule.

Sure. (And it's a good point to make.)



--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

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!



--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

David Brown <david.brown@hesbynett.no> writes:

On 01/06/2026 00:54, Keith Thompson wrote:

[...]

(INT_MIN + INT_MAX) + 1 is well defined. (INT_MIN + INT_MAX) +1
is equivalent, and is also well defined. INT_MIN + (INT_MAX +1)
has undefined behavior.

Oops, I forgot to delete some parentheses. I meant to write that
INT_MIN + INT_MAX + 1 is equivalent to (INT_MIN + INT_MAX) + 1.
The redundant parentheses don't impose any change in semantics.

Compilers can re-arrange integer arithmetic, despite new overflows, if
they know the result is the same. On pretty much any current
processor, a compiler generating code for integer "a + b + c" could do
the additions in any order - treating the operations as commutative
and fully associative. The final result will be the same in every
case where the original expression did not overflow (i.e., every case
with defined behaviour).

Right, good point. Since (INT_MIN + INT_MAX) + 1 is well defined,
if a compiler rearranges it so it evaluates INT_MAX + 1 as an
intermediate result, that's permitted **if** the result is the same.
(It makes more sense if the operands are variables with those values
rather than constants.) A compiler can take advantage of how the
hardware works. UB applies to the C source code, not (necessarily)
to the operations that are performed by the actual machine. If it
generates code that yields the correct result by consulting a Ouija
board, that's still conforming.

[...]

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

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 */

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

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.

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

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".



--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

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.

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

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.




--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

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.

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

In article <10vjdn8$22tgu$1@dont-email.me>,
David Brown <david.brown@hesbynett.no> 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 :-)

Hey now. Some of us have programmed in Lisp professionally, and
rather enjoy it.

Lisp is often maligned for its parentheses; I don't think that's
fair. They really aren't that onorus once you start working in
it, and they're unambiguous; one may of the structure of Lisp
code as a shorthand notation for the resulting program's AST.

(And for too few parentheses, any source code in Forth.)

No comment.

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.

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.

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!

Not to mention symbolic names for the magic constants. :-/

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.

- Dan C.


--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

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:

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 :-)

Hey now. Some of us have programmed in Lisp professionally, and
rather enjoy it.

Lisp is often maligned for its parentheses; I don't think that's
fair. They really aren't that onorus once you start working in
it, and they're unambiguous; one may of the structure of Lisp
code as a shorthand notation for the resulting program's AST.

I did include a smiley - I know there are people here who enjoy working
with LISP, and have probably heard a few too many jokes about parentheses!

(And for too few parentheses, any source code in Forth.)

No comment.

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.

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.)

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!

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.

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).



--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

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?

Any source code written in LISP :-)

Hey now. Some of us have programmed in Lisp professionally, and
rather enjoy it.

Lisp is often maligned for its parentheses; I don't think that's
fair. They really aren't that onorus once you start working in
it, and they're unambiguous; one may of the structure of Lisp
code as a shorthand notation for the resulting program's AST.

I did include a smiley - I know there are people here who enjoy working
with LISP, and have probably heard a few too many jokes about parentheses!

It's fine; many variants of Lisp are deserving of criticism, and
that community has a tendency to get too touchy about defending
the language's honor. People like Stallman are fond of calling
Lisp "the most powerful language" but I think that's nonsense.

A problem with many Lisp variants is that they're dynamically
typed; I once had to fix a production outage that happened with
a programmer converted a pair of integers into a triple. The
pair had been represented using a single `CONS` cell, but when
it became apparent that a triple was needed, it was changed into
a proper list. The operation for retrieving the first half of a
`CONS` cell is `CAR`; the operation for retrieving the second
half is `CDR`. Lisp hackers usually refer to the two halves as
"the CAR" and "the CDR" of the cell.

If a `CONS` cell just holds a pair of scalar values, as in this
example, these functions give back those scalars. However,
lists are built from `CONS` cells, where the CAR of the list is
the first element, and the CDR is the tail of the list, which is
itself a list.

Anyway, to access the values from the pair, the programmer used
`CAR` and `CDR`, but when the pair was converted to a list, this
was no longer correct; the first element was still accessible as
the CAR, but the CDR was now a list; to get the second element
of the list one would use `CADR` (or the better named `SECOND`).

Unfortunately, the programmer missed one place, and passed the
CDR of the list to a function that expected a `FIXNUM` and tried
to do arithmetic on it. Lisp is usually strongly typed, so you
can't just add a list to a number; that raises a "condition"
(which is like an exception, though that you can often restart
the thing that raised the condition). In this program, that
resulted in an ISE and an error returned to the user.

The fix was trivial, but it struck me at the time that in a
statically typed language it would have been a compile time
error.

(And for too few parentheses, any source code in Forth.)

No comment.

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.

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.

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! >>

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.

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.

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.

- Dan C.


--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

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.)

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

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 */

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)