31–40 of 120 posts
Why don't compilers have an option to reject UB with an compiler error? Surely the compiler must know when it comes across a piece of source code whose semantic is undefined.
Rather they are written under the assumption that there are no UB in the program, and the chips fall where they may as these assumptions are used and propagated.
I wonder why he mentions this TIS interpreter but not the development of complete semantics for C and specifically the k framework ( https://github.com/kframework/c-semantics ). Afaik, kcc is also really good at finding undefined behavior. Regehr even wrote about it in the past ( https://blog.regehr.org/archives/523 ).
Another reason to mention TIS-interpreter specially is that Pascal Cuoq (the co-author of this blog post) is one of its developers, and his livelihood depends on it being used.
How many of these 200+ undefined behaviours exist in more modern low-level languages, such as Rust and D?
In Rust it's pretty limited. Here is the full list, from the Rustonomicron: Dereferencing null or dangling pointers Reading uninitialized memory Breaking the pointer aliasing rules Producing invalid primitive values: dangling/null references a bool that isn't 0 or 1 an undefined enum discriminant a char outside the ranges [0x0, 0xD7FF] and [0xE000, 0x10FFFF] a non-utf8 str Unwinding into another language Causing a da…
It's true that unsafe is needed to get these problems, but they can also occur outside of unsafe blocks. See an example here: https://gankro.github.io/blah/only-in-rust/#unbound-lifetime...
Your own code need not use "unsafe" at all, but the program may still crash in your code if you called some function that internally does unsafe things to mess up your memory.
EDIT: I should say that the linked code does not crash, it only reads uninitialized memory. It seems to me like the same hole could be used to make things crash, but I don't have a ready-made example.
I wish there was a GCC switch that made the optimizer go "This is clearly undefined behaviour. I'll stop this compile right here", as opposed to "This is clearly undefined behaviour. Sweet jackpot, it means I can do whatever the heck I want. Drop those NULL checks below, I've got the golden UDB ticket now"
The optimizer doesn't work that way. It assumes the code does not do UB and then removes branches that can never be taken if the code executes no UB. That's different from "This is UB, and now I do ...".
How many of these 200+ undefined behaviours exist in more modern low-level languages, such as Rust and D?
LuaJIT is another modern low-level language. It has some remarkable undefined behavior like the evaluation order for function arguments. Scares me a bit. https://github.com/LuaJIT/LuaJIT/issues/238
unspecified != undefined behavior
See this Stack overflow answer for an explanation: https://stackoverflow.com/questions/2397984/undefined-unspec...
Earlier quoted context omitted.
Because a lot of UB cannot be efficiently determined at compile time. Hence, UBSan.
It is very easy to be efficiently determined at compile time, other systems programming languages do it, by not having UB on their language standard to start with. If people prefer "performance trumps correctness" and "winning compiler benchmarks is what counts" then they should happily keep getting exploited.
And yes, if you want to allow manual allocation of objects and setting pointers to arbitrary objects, then your two choices are: 1) garbage collection 2) undefined behavior (use-after-free, double-free, dangling pointers, etc.)
Earlier quoted context omitted.
The optimizer doesn't work that way. It assumes the code does not do UB and then removes branches that can never be taken if the code executes no UB. That's different from "This is UB, and now I do ...".
I think we deserve a compiler warning whenever a source line of code (not a line generated by the preprocessor) gets removed due to UB exploitation. All such cases are worth the programmer's attention, because they are either useless lines or bugs.
Earlier quoted context omitted.
It is very easy to be efficiently determined at compile time, other systems programming languages do it, by not having UB on their language standard to start with. If people prefer "performance trumps correctness" and "winning compiler benchmarks is what counts" then they should happily keep getting exploited.
"Very easy" - well, if you think garbage collection is easy... And yes, if you want to allow manual allocation of objects and setting pointers to arbitrary objects, then your two choices are: 1) garbage collection 2) undefined behavior (use-after-free, double-free, dangling pointers, etc.)
Garbage collection isn't the only way of writing mostly safe systems programs.
ESPOL, NEWP are 10 year older than C.
PL/8 was the systems programming language used by IBM for their first RISC mainframe, followed by PL/S.
Mesa used at Xerox PARC.
Modula-2 used at ETHZ and many 16 bit systems.
Object Pascal used to write the first versions of Mac OS and Lisa.
Ada and SPARK used by high integrity systems where human lives can be at risk.
All of them with not even a quarter of C's UB collection.
How many of these 200+ undefined behaviours exist in more modern low-level languages, such as Rust and D?
In Rust it's pretty limited. Here is the full list, from the Rustonomicron: Dereferencing null or dangling pointers Reading uninitialized memory Breaking the pointer aliasing rules Producing invalid primitive values: dangling/null references a bool that isn't 0 or 1 an undefined enum discriminant a char outside the ranges [0x0, 0xD7FF] and [0xE000, 0x10FFFF] a non-utf8 str Unwinding into another language Causing a da…
Correct me if I'm wrong but I don't think such a strong universal statement can be true (even outside unsafe blocks) because LLVM has corner cases of "undefined behavior". (And since Rust is relies on LLVM, ...)
Maybe it's more accurate to say that Rust minimizes undefined behavior as a design goal, or it doesn't have intentional undefined behavior.
Earlier quoted context omitted.
In Rust it's pretty limited. Here is the full list, from the Rustonomicron: Dereferencing null or dangling pointers Reading uninitialized memory Breaking the pointer aliasing rules Producing invalid primitive values: dangling/null references a bool that isn't 0 or 1 an undefined enum discriminant a char outside the ranges [0x0, 0xD7FF] and [0xE000, 0x10FFFF] a non-utf8 str Unwinding into another language Causing a da…
> Note that all of these are inside of unsafe blocks. Besides unsafe blocks, Rust has no undefined behavior, and the compiler will prevent you from doing any of these things. It's true that unsafe is needed to get these problems, but they can also occur outside of unsafe blocks. See an example here: https://gankro.github.io/blah/only-in-rust/#unbound-lifetime... Your own code need not use "unsafe" at all, but the pro…