C and Undefined Behaviour

https://www.lelanthran.com/chap14/content.html

by lelanthran • 5 months ago

18 12 5 months ago

hyperhello• 5 months ago

My understanding of UB is that in programming, there are corner cases which should be ignored by the language system. For example, C writing to a zero pointer is not “wrong”, you told it to write there when you dereferenced a zero pointer and assigned a value. The effects and the mitigation thereof just need to be outside the language, because otherwise you are saying that each and every memory access needs to be checked. So UB is just the language system saying “hey, I don’t know what happens, and we are not going to guarantee anything, and you can expect the world to explode if you do this, but not really, but yes really.”

AlotOfReading3• 5 months ago

That would be a much nicer definition of UB than is actually the case. What the standards say is that a program that writes to a null pointer (distinct from a zero pointer) is semantically meaningless. The compiler can assume the write doesn't happen at all, call some other functions first, initialize the pointer with a value it takes later, or whatever else it wants. One effect of this is so-called "time-traveling", where the entire execution trace before the point of UB in the execution trace is also semantically undefined. C23 updated to clarify that time travel isn't a valid interpretation, but it remains valid in C++.

thezipcreator• 5 months ago

little did we know, to create a time machine all we needed to do was to compile some undefined behavior with the correct compiler

nrds2• 5 months ago

Is it even worth pointing out that the author misunderstands how UB works in Rust, given that at this point such a misunderstanding has to be willful than otherwise? There is _no_ UB in the safe subset of Rust, and in mixed safe-unsafe rust, the UB can only originate in the unsafe blocks.

In modern C++ (i.e. with smart pointers) something similar is true in that the UB can only occur in code dealing with certain types and functions (e.g. raw pointers), and not other types and functions. It's really the same as rust, just without the compiler support and the explicit unsafe blocks.

accelbred• 5 months ago

I think you are entirely missing the author's point. The author is generalizing from the specific technicalities of C/Rust/etc UB, to the problem with UB which is that should it be triggered, then you can't know what the program will do. This does not have to be the result of language specification. If writing safe Rust yourself, yes no UB will occur usually, and you can know what will happen based off of what code you wrote. The author extends UB to vibecoding where there is no specification to understand the translation of prompts to code. Without thorough review, you are unable to be sure that the output code matches the intent of your prompting, which is analagous to writing code with UB. The issue the author has with vibecoded Rust is not that the code can trigger undefined behavior at the language layer, but that the perfectly "safe" code generated may not at all match the intended semantics.

AlotOfReading3• 5 months ago

The problem with the author's argument is the inductions don't follow from the premise. With defined C, you can in principle look at a piece of code and know what it will do in the abstract machine (or at least build a model dependent on assumptions about things like unspecified behavior). Actually doing this may be practically impossible, but that's not the point. It's not possible in the presence of UB. You can't know what a piece of code containing UB will do, even in principle.

You can in principle read the LLM's output and know that it won't put your credentials on the net, so it's not the same as UB. Maybe there are practical similarities to UB in how LLM bugs present, but I'm not sure it's a useful comparison and it's not the argument the author made.

nrds2• 5 months ago

If that's the author's point then the article needs a rewrite. I suspect that was _not_ the author's point and it's offered as a good faith but misplaced post-hoc justification.

rramadass• 5 months ago

The article is really about the dangers posed by the concept of UB (https://en.wikipedia.org/wiki/Undefined_behavior) extended to any language when the programs are LLM generated.

C and Undefined Behaviour

Related Stories