Our great sponsors
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
What makes you think they don't understand it? They acknowledge that it is UB. I read them as realistic, since they know that people rely on C compilers work in a certain way. They even wrote an interpreter that detects UB: https://github.com/TrustInSoft/tis-interpreter
I understand why people like the compiler being able to leverage UB. I suspect this philosophy actually makes Trust-In-Soft more money: You could argue that if there was no UB, there would be no need for the tis-interpreter.
So isn't it in fact quite self-less that they encourage the world to optimize a bit less (spending more money on 'compute'), while standing to profit from the unintended behaviour they'd otherwise be contracted to help debug?
If a --k&r mode was to be reliable, wouldn't it need to get specified first? Otherwise people would start relying on some edge case.
If speed is not a requirement for the --k&r mode, you could just take the tis-interpreter and note that if it runs without UB, it is still much faster than an actual computer was when k&r were active.
Would it even be possible to specify a variant of C that contains no UB (e.g. would define exactly what happens on unaligned access), but can compile practical existing C89 programs? I wonder if it could be written such that it could actually specify the behaviour consistently across the language intersection supported by both of e.g. GCC 2.95 and Chibicc[0].
Or maybe there are so many bugs in GCC 2.95 that it would simply be infeasible? How much time would it take to specify?
[0]: https://github.com/rui314/chibicc