|
|
Subscribe / Log in / New account

Bjarne Stroustrup’s Plan for Bringing Safety to C++ (The New Stack)

Bjarne Stroustrup’s Plan for Bringing Safety to C++ (The New Stack)

Posted Nov 5, 2023 20:12 UTC (Sun) by jem (subscriber, #24231)
In reply to: Bjarne Stroustrup’s Plan for Bringing Safety to C++ (The New Stack) by khim
Parent article: Bjarne Stroustrup’s Plan for Bringing Safety to C++ (The New Stack)

Once more: consider the following code:

void foo(int x) {
  int y = x;
}

This piece doesn't include UB, doesn't do anything strange, it only does one simple (if useless) assignment.

But if you remove that assignment you may break some other piece of code!

The code that relies on this assignment does exhibit undefined behaviour: it uses the value of an uninitialised variable. I can't understand why anyone would want to write code like this, which assumes that a function local variable occupies the same address as a variable in a previously called function that has already returned. I don't see the usefulness of this, and even the most junior programmer should realise this is an extremely risky piece of code. This has got nothing to do with the compiler taking advantage of UB to optimise code. Just normal compilers optimisations like deleting the unused variable results in a non-working program.

One could even argue that your program is broken even if it was written in pure assembly language. The stack slot the popped variable occupied is not part of the stack anymore, and I can imagine target machines where the stack grows and shrinks automatically. On such a machine the physical page could be unmapped as soon as the hardware detects that the stack has shrunk past the page border.


to post comments

Bjarne Stroustrup’s Plan for Bringing Safety to C++ (The New Stack)

Posted Nov 5, 2023 21:50 UTC (Sun) by khim (subscriber, #9252) [Link] (2 responses)

> I can't understand why anyone would want to write code like this, which assumes that a function local variable occupies the same address as a variable in a previously called function that has already returned.

Computer can't understand that, either. Because it couldn't understand anything at all. It doesn't have conscience or common sense.

> I don't see the usefulness of this, and even the most junior programmer should realise this is an extremely risky piece of code.

So what? Remember the context here: If you follow the discipline above, all optimization levels behave the same way, so why talk about -O0?

If you so pompously proclaim that there are some magic discipline which allows you to optimize any code without relaying on the absence of UB then you have to explain how it works on this example (and on other, even more convoluted examples, too).

Or, if you don't plan to optimize any working code then you have to explain why this piece of code is not deserve all optimization levels behave the same way treatment without adding things like I don't see the usefulness of this or I can't understand why anyone would want to write code like this. If you can not do that then your proclamations about how there are “benigh optimizations that don't rely on the absence of UB” are exposed as lies.

> This has got nothing to do with the compiler taking advantage of UB to optimise code.

This had got everything to do with compiler taking advantage of absence of UB to optimize code.

You either say that code which hits UB at runtime may not preserve behavior after optimization or, alternatively, be prepared how to optimize any code that predictably works without optimizations. And any means any here, not just “the code I may want to write”.

> One could even argue that your program is broken even if it was written in pure assembly language.

It works, sorry.

> The stack slot the popped variable occupied is not part of the stack anymore, and I can imagine target machines where the stack grows and shrinks automatically.

Sure, but x86-64 doesn't behave that way.

> On such a machine the physical page could be unmapped as soon as the hardware detects that the stack has shrunk past the page border.

How is that relevant? On x86-64 red zone is large enough to keep values from being overwritten. And O_PONIES lovers always talk about how they have the right to take advantage of any and all quirks of the target platform and yet compiler have to process such programs anyway… I'm not using anything beyond that here.

Bjarne Stroustrup’s Plan for Bringing Safety to C++ (The New Stack)

Posted Nov 6, 2023 7:49 UTC (Mon) by jem (subscriber, #24231) [Link] (1 responses)

>This had got everything to do with compiler taking advantage of absence of UB to optimize code.

Ok, then why are you using code with UB to prove your point? I am talking about the "other piece of [C] code".

Anyway, this discussion isn't leading anywhere, so I am out.

Bjarne Stroustrup’s Plan for Bringing Safety to C++ (The New Stack)

Posted Nov 6, 2023 8:03 UTC (Mon) by mb (subscriber, #50428) [Link]

> Ok, then why are you using code with UB to prove your point? I am talking about the "other piece of [C] code".

The code is "programmed to the machine" and the compiler is expected to just emit instructions and the behavior shall be whatever the machine's stack would do.
The compiler breaks this by optimizing away the stack store, because the whole program is undefined in the language machine model.

"Programming to the hardware" is fundamentally broken.


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds