6 ms·
Presumably Martin intends the usual caveat that this is subject to bugs. So, "there might be a bug in the compiler" isn't interesting. There are bugs in LLVM, b
by tialaramex 4d ago
Presumably Martin intends the usual caveat that this is subject to bugs. So, "there might be a bug in the compiler" isn't interesting. There are bugs in LLVM, bugs in Rust's trait resolution, bugs in Javascript implementations, obviously code has bugs and that's generally not very interesting - we can fix bugs.
Are you claiming that there must be such transforms or only that it is likely that bugs exist which isn't interesting.
- mirashii 4d agoNeither. I'm claiming that UB allows a transform that violates or ignores the additional guards put in place by Fil-C, and by the definition of UB that is not a bug in the compiler, as any behavior is allowable. To assert that something specific always happens under UB is counter to the definition of UB. Fil-C carefully defines away UB for some operations, but to make full guarantee of safety, even by their definition and modulo bugs, I believe it necessary to fully remove UB.
- tialaramex 4d agoMaybe it was unclear that Fil-C is a compiler. So the thing doing those transforms you're worried about is Fil-C. Fil-C gets to look at some code which has UB if variable z is 9 and go "OK, lets check whether z is 9, and if so...". The result, of course, is much, much slower than executables from a typical modern C compiler, but since "It always does X" is in fact a permitted implementation of "Undefined Behaviour" this is a compliant C implementation, at least in most observable respects.