Wolf480pl

(replying to Wolf480pl)

@saagar

That being said I agree that teaching "UB is black box" is wrong. It's best to show an example how a seemingly innocent UB can cause an optimizing compiler to make assumptions and delete half of your code.
2/2

Saagar Jha

(replying to Wolf480pl)
@wolf480pl I bring this up mostly because people who have been trained that UB is only bad without truly understanding it make poor choices about what they think ought to be in the standard
1 replies →
1 replies

Wolf480pl

(replying to Saagar Jha)

@saagar IIRC there's also Implementation-Defined Behaviour which is less evil than UB because it requires the compiler to pick a behaviour upfront and be consistent with it.

Saagar Jha

(replying to Wolf480pl)
@wolf480pl Yeah my past discussion with people I think the viewpoint I have aligned with this one is that trapping should be a permitted implementation-defined behavior and for clearly broken constructs the only permissible behavior

Wolf480pl

(replying to Saagar Jha)

@saagar I don't know enough / haven't thought about it enough to have a definitive opinion on what should be done with UB.

But I kinda like zig's Debug / ReleaseSafe / ReleaseFast build modes.
Debug and ReleaseSafe trap on UB, ReleaseFast assumes no UB and optimizes as much as it can.

Saagar Jha

(replying to Saagar Jha)
@wolf480pl For what it’s worth I am in favor of abolishing undefined behavior by default but surprisingly few people agree with me on how to do that in a security-focused way

Wolf480pl

(replying to Saagar Jha)

@saagar well -O3 isn't a default :P

Saagar Jha

(replying to Wolf480pl)
@wolf480pl Despite my insistence that people who want portable assembler should use -O0, compilers can and do generate code assuming a lack of UB even at that optimization level
2 replies →
2 replies

Wolf480pl

(replying to Saagar Jha)

@saagar oof

lonjil

(replying to Saagar Jha)

@saagar @wolf480pl it's sort of impossible not to. Any transformation of code, no matter how simply, has to rely on the idea that the behavior of the code is the same before and after the transformation. And if there is no known behavior (because UB) you're outta luck.

Wolf480pl

(replying to lonjil)

@lonjil @saagar you (a compiler author) can still define the behaviour yourself, document it, then stick to it

lonjil

(replying to Wolf480pl)

@wolf480pl @saagar there's some low hanging fruit in C that's easy enough to define, but a lot of UB in C is very hard to define, at least on normal hardware.

(and you're probably not defining things differently at O0 and O3, I think?)

Wolf480pl

(replying to lonjil)

@lonjil @saagar no I actually mean define them only at O0 :P
Define them to do something dumb and potentially dangerous but predictable.
Bonus points if it matches most people's idea of a "a high-level assembly"

Wolf480pl

(replying to Wolf480pl)

@lonjil @saagar for example, have -O0 imply -fwrapv

Saagar Jha

(replying to Wolf480pl)
@wolf480pl @lonjil This is awful

Wolf480pl

(replying to Saagar Jha)

@saagar @lonjil but that's what you'd expect from a "high level assembly", right?

I'm not saying anyone should do that, just that there is a way to make O0 behave more like assembly

Saagar Jha

(replying to Wolf480pl)
@wolf480pl @lonjil I would generally want to divorce “do what I mean” from default debug builds tbh