UBSan ␇ Runtime
reviews.llvm.org
reviews.llvm.org
It seems like the font is specified as:
font: 13px 'Segoe UI','Segoe UI Emoji','Segoe UI Symbol','Lato','Helvetica Neue',Helvetica,Arial,sans-serif;
I guess I have the emoji and symbol font installed for Segoe UI and not the main font.
This runtime will emit sound, most traditionally the terminal's bell sound, when undefined behavior occurs.
I'm surprised this is possible. My understanding was that compilers don't consciously check for UB and then decide to make the dev's life hell if they find some. It's more that compilers pretend that certain assumptions are true even though this cannot actually be verified. If they happen to not be true (but the compiler still behaves as if they were), undefined behaviour occurs.
So if you can explicitly check for code that causes UB, why permit it at all? Why not abort compilation or at least emit a warning?
Yet, this patch is fun answer to those people who are annoyed by the number of errors that running their codebase through ubsan will produce and might think "that's just for edge cases, I'm pretty sure in practice I'll never hit effects of those at runtime". Compile with ubsan_bel and listen in horror how often it actually happens....
> Yes, this is April 1st and the patch isn't particularly serious.
Yeah, I'm surprised that the terminal bell still exists in 2020.
>My understanding was that compilers don't consciously check for UB and then decide to make the dev's life hell if they find some.
That was the case during the 20th century. In the 20 years compilers have gotten far more aggressive. They do actively check for UB.
>It's more that compilers pretend that certain assumptions are true even though this cannot actually be verified.
What often happens is that UB gets detected and information that is clearly available in the source code gets erased in the compiler to follow the letter of the standard. There is a lot of UB code that can run without problems if the compiler didn't interfere.
>So if you can explicitly check for code that causes UB, why permit it at all? Why not abort compilation or at least emit a warning?
A lot of UB can only be detected at runtime. The most sensible interpretation of UB would be to simply skip these checks in production builds but keep them in debug builds so that developers can avoid UB in their code.
Example: Bitshifting can result in UB but if both operands are variables the UB can be detected at runtime.
I'm not sure how much I agree with this. I agree that compilers have gotten a lot better about deriving information from UB analysis in the past decade or two, but I think a lot of the time it gains information from the additional analysis rather than ignoring existing information.
The main example I can think of for a compiler ignoring information from the source code is strict aliasing, where the compiler can ignore the fact that two addresses can be statically proven to point to the same memory location [0] (although to be fair that's from 2009; I'm not sure whether GCC still does this).
For stuff like null pointer dereferences, signed overflow, or OOB dereferences, though, the compiler can (sometimes?) derive stricter bounds, which means the compiler is gleaning more information from the source code than it has previously.
[0]: https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg...
Why? Given that terminals still exist in 2020, it's just as useful today as when it was conceived - if anything moreso, since we often have dozens of terminals to monitor. On many systems a terminal bell will even result in a desktop notification - lovely!