
UBSan ␇ Runtime - gok
https://reviews.llvm.org/D77219
======
tyilo
Off-topic: I get the same weird font display on this site as on microsoft's
login page.

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;
    

and the first font I have avaiable seems to be Segoe UI Emoji and Segoe UI
Symbol, which looks horrible:
[https://i.imgur.com/KS19dRA.png](https://i.imgur.com/KS19dRA.png) Removing
them both from the list gives the following result:
[https://i.imgur.com/ReI0W4Z.png](https://i.imgur.com/ReI0W4Z.png)

I guess I have the emoji and symbol font installed for Segoe UI and not the
main font.

~~~
tyilo
Hmm, I fixed it by uncommenting the lines for matching Segoe UI Emoji and
Segoe UI Symbol. /etc/fonts/conf.avail/75-joypixels.conf

------
xg15
Question to people with more knowledge in the matter:

 _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?

~~~
imtringued
>I'm surprised this is possible.

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.

~~~
aw1621107
> 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.

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...](https://www.mail-archive.com/linux-
btrfs@vger.kernel.org/msg01647.html)

------
trelliscoded
On the mac it opens a youtube video if you hit over 9000 undefined
behaviors...

