| ▲ | What every compiler writer should know about programmers (Anton Ertl, 2015) [pdf](complang.tuwien.ac.at) | |||||||
| 33 points by tosh 4 days ago | 4 comments | ||||||||
| ▲ | Joker_vD a minute ago | parent | next [-] | |||||||
In the end it all boils to a very simple argument. The C programmers want the C compilers to behave one way, the C implementers want the C compilers to behave the other way. Since the power structure is what it is — the C implementers are the ones who write the C standard and are the ones who actually get to implement the C compilers — the C compilers do, and will, behave the way the C implementers want them to. In this situation the C programmers can either a) accept that they're programming in a language that exists as it exists, not as they'd like it to exist; b) angrily deny a); or c) switch to some other system-level language with defined semantics. | ||||||||
| ▲ | ameliaquining 3 hours ago | parent | prev | next [-] | |||||||
Previously: | ||||||||
| ▲ | zephen an hour ago | parent | prev [-] | |||||||
Here's a cogent argument that any decision by compiler writers that they can do whatever they wish whenever they encounter an "undefined behavior" construct is rubbish: https://www.yodaiken.com/2021/05/19/undefined-behavior-in-c-... And here's a cautionary tale of how a compiler writer doing whatever they wish once they encounter undefined behavior makes debugging intractable: https://www.quora.com/What-is-the-most-subtle-bug-you-have-h... | ||||||||
| ||||||||