[compiler-guy]

We will be hobbled with these decisions for a long time precisely because the complete package of trade offs the designers made were so successful.

If they had gone for wart-free on properly powered hardware, they would be stuck back in Multics land or living with the gnu Hurd—cancelled for being over budget or moving so slowly that projects that actually accomplish what the users need overtake them.

Do I wish that C had fixed its operator precedence problem? Sure. But the trade offs as a total package make a lot of sense.

[pjmlp]

Some would say,

https://multicians.org/history.html

Instead we pile mitigations on top of mitigations, with hardware memory tagging being the last hope to fix it.

[colejohnson66]

Is there an explanation on why C’s operator precedence is weird? Such as: why does the bitwise AND have higher precedence than logical AND?

[compiler-guy]

There is, and it is amusing

“In retrospect it would have been better to go ahead and change the precedence of & to higher than ==, but it seemed safer just to split & and && without moving & past an existing operator. (After all, we had several hundred kilobytes of source code, and maybe 3 installations....)“

https://www.lysator.liu.se/c/dmr-on-or.html

[briantakita]

> why does the bitwise AND have higher precedence than logical AND?

Why is this precedence weird? Bitwise AND tends to be used to transform data while a logical AND tends to be used for control flow.

[colejohnson66]

I meant equals having a higher precedence than bitwise AND.

As in:

    if (x & 2 == 2)

...is actually parsed as:

    if (x & (2 == 2))

...which isn’t intuitive.

[compiler-guy]

See the above example from dmr himself