ralfjung

6 ms·

1.
by ralfjung 7y ago
I added a few sentences about that to the post: > In the case of our example, the program actually compares such an “unobservable” bit pattern with a constant, so the compiler constant-folds the result to whatever it pleases. Because th
2.
by ralfjung 7y ago
> Trying to figure out what a compiler might do in the face of undefined behavior is generally not a worthwhile exercise. That is exactly the point of my post! If you think I disagree with that statement, we seriously miscommunicated som
3.
by ralfjung 7y ago
The argument for C not being low-level is not via UB, it is via the fact that a lot happens when C gets translated to assembly, and to explain that you need to consider an abstract machine that is many things, but not low-level.
4.
by ralfjung 7y ago
The standard will not specify anything, so what the compiler outputs is gibberish. You are literally looking at a sequence of bytes on which no constraints whatsoever are imposed. LLVM could have compiled my UB program do `0xDEADBEEF` (whic
5.
by ralfjung 7y ago
> I wonder why the optimiser didn't choose false and let the assert pass? I don't know exactly, but it's kind of a moot point. I would have negated the statements until I found a way to make it return what I want it to. Th
6.
by ralfjung 7y ago
Another argument for considering the abstract machine as the primary way to think about programs in a language is that it is very easy to end up with a set of optimizations that all look reasonable in isolation but are inconsistent, and lea
7.
by ralfjung 7y ago
AFAIK in Ada, deallocating memory is unsafe. So I'd say it has some catching-up to do when compared with safe Rust in that regard. And Rust of course has a two-element type, it is called `bool`. That said, Ada certainly got many thin
8.
by ralfjung 7y ago
Thanks, I have added a link to that LLVM document to the post!
9.
by ralfjung 7y ago
Hm, good point about the bitfields. The paper I cite [1] actually talks specifically about bitfields as their precise semantics in the presence of "poison"-style uninitialized memory is not entirely clear yet. [1]: http:/&#x
10.
by ralfjung 7y ago
> I don't think this is really right. He claims that uninitialised memory is not just random bytes, but it is! No it's not. To describe the behavior of a program involving uninitialized memory (like the example in my post), at
11.
by ralfjung 7y ago
> Unfortunately no, that's not and has never been how undefined behaviour works. Undefined behaviour anywhere in your program invalidates the whole program and can lead to arbitrary behaviour anywhere else in your program (this has
12.
by ralfjung 7y ago
Good point, I should have at least mentioned that there is an "abstract machine" when I introduce this strange kind of memory. Thanks for the feedback!
13.
by ralfjung 7y ago
I don't think I got any of it wrong, but in case I did I'd appreciate if you could point out my mistake(s). :)
14.
by ralfjung 7y ago
You are making exactly the mistake the post is all about. :) Only UB-free programs can be made sense of by looking at their assembly . Whether a program has UB is impossible to tell on that level. For that, you need to think in terms of
15.
by ralfjung 7y ago
That and it is really tedious to spell out "less than or equal to", in German we have a much shorter phrase for it ("kleiner-gleich"). But thanks for pointing out this mistake, I will fix it immediately.
16.
by ralfjung 7y ago
> Understanding how your compiler enforces it's abstract machine is beneficial The compiler does not enforce it though. It only implements the abstract machine, and the implementation is only correct for UB-free programs.
17.
by ralfjung 7y ago
> The assembly has to enforce the abstract machine. The assembly has to implement the abstract machine only if your program has no UB . The assembly never has to check if memory is "initialized" or not even though that distinc
18.
by ralfjung 7y ago
I think thinking about real hardware (most of the time) just distracts from thinking about what your program "actually does", which is specified by the abstract machine. By thinking in terms of the abstract machine, you can forge
19.
by ralfjung 7y ago
IMO the real machines are much more distracting than the abstract ones. ;)
20.
by ralfjung 7y ago
You could always say that wrap-around has to either (a) cause SIGILL or (b) return the wrapped-around result. That still allows linting with a sanitizer without involving any UB at all. This is effectively what Rust does (replace "SIGI
21.
by ralfjung 7y ago
Which major compiler is mostly implemented by academics? Neither GCC nor LLVM, for sure. Us academics do have a lot of "fun" figuring out a way to put what the compiler developers do on solid footing [1]. But this is a game of w
22.
by ralfjung 7y ago
UB has [developed a lot][1] since then. Now UB is a way for the programmer to help the compiler generate better code by providing extra information that is hard for the compiler to prove itself. I think, in general, this is actually an inge
23.
by ralfjung 8y ago
> the author is trying to reconcile two fundamentally irreconcilable ways of looking at memory: on the one hand, the machine view of a single address space, and on the other, the program view of distinct variables That's not incorre
24.
by ralfjung 8y ago
This is an extremely good question, and I do not have a satisfying answer. Note that `malloc` is special in the C standard as well, and AFAIK it is not possible to implement `malloc` in standard C at all. Heck, there are several models of
25.
by ralfjung 8y ago
This is looking at the wrong level of abstraction though. The compiler will already optimize your code in a way that multiple uses of the same uninitialized value can produce different results. Arguing about these assembly/CPU-level
26.
by ralfjung 8y ago
> using em dashes despite space-separated en dashes being more popular is another (though that one varies by locale) Okay so I was told in my English writing class that in US English one uses the longer em dashes without spaces. But I j
27.
by ralfjung 8y ago
TBH I just wanted to mention both of these things in the title so I stuffed them both in.^^ (I'm also not a native speaker so I kind of borrow what I see. And Dr. Strangelove was probably where I was this kind of title for the first t
28.
by ralfjung 8y ago
The sad truth is that I have seen, several times, people justifying real code doing questionable things with pointers in C(-like languages) by saying "well but pointers are just integers". I am not sure what the best way to teach
29.
by ralfjung 9y ago
I can perfectly agree to much of what they say, but here... > The C language is old and boring. It is a well-known and well-understood language. ...I think they are very fundamentally mistaken. C is a horribly complicated language. It