Why undefined behavior may call a never-called function
kristerw.blogspot.com
Why undefined behavior may call a never-called function
1–10 of 183 posts
Re: Why undefined behavior may call a never-called function
#2Interesting choice of code for a demo. I wonder if anyone hosed themselves running this.
It seems gnu rm has "-preserve-root" as a default, but that's not guaranteed to be on every rm.
Re: Why undefined behavior may call a never-called function
#3Interesting choice of code for a demo. I wonder if anyone hosed themselves running this. It seems gnu rm has "-preserve-root" as a default, but that's not guaranteed to be on every rm.
One of the advantages of using Docker! You can safely run this code multiple times and play with it without affecting your machine.
Re: Why undefined behavior may call a never-called function
#4Interesting choice of code for a demo. I wonder if anyone hosed themselves running this. It seems gnu rm has "-preserve-root" as a default, but that's not guaranteed to be on every rm.
One of the advantages of using Docker! You can safely run this code multiple times and play with it without affecting your machine.
Sure, but you could also replace "rm -rf /" with "id" or something else non destructive. Somebody is going to copy paste that snippet and have a bad day.
Re: Why undefined behavior may call a never-called function
#5Interesting choice of code for a demo. I wonder if anyone hosed themselves running this. It seems gnu rm has "-preserve-root" as a default, but that's not guaranteed to be on every rm.
One of the advantages of using Docker! You can safely run this code multiple times and play with it without affecting your machine.
Do you use Docker to run literally every piece of code though?
Re: Why undefined behavior may call a never-called function
#6If you make one small change to this file you can cause clang and gcc to both prevent this from compiling if you are using warnings.
namespace {
void NeverCalled() { Do = EraseAll; }
}
Results in warning: unused function NeverCalled.
In general this is best practice for functions defined and used in a single translation unit.
Re: Why undefined behavior may call a never-called function
#7Very interesting, to me seems like a "compiler bug". The compiler should not automatically set the static pointer value if the function that sets it is never called.
Anyway, I guess "undefined behavior" is really undefined and it means anything can happen, so as per specs it's not a bug. Ultimately it's the programmer's mistake for having undefined behavior in his code.
Re: Why undefined behavior may call a never-called function
#8Very interesting, to me seems like a "compiler bug". The compiler should not automatically set the static pointer value if the function that sets it is never called. Anyway, I guess "undefined behavior" is really undefined and it means anything can happen, so as per specs it's not a bug. Ultimately it's the programmer's mistake for having undefined behavior in his code.
Unfortunately, "it's not a bug, it's a feature!" -- there are long-standing design choices in C/C++ where various circumstances are explicitly designed to yield "undefined" behavior where literally anything goes. I believe the original intent of these are to give the compiler/optimizer more room to speed up the executable.
Edit: The 'undefined' clause here is due to invoking a function at address 0, rather than any lack of variable initialization (since global variables are automatically initialized to 0, as the poster below points out).
Re: Why undefined behavior may call a never-called function
#9Very interesting, to me seems like a "compiler bug". The compiler should not automatically set the static pointer value if the function that sets it is never called. Anyway, I guess "undefined behavior" is really undefined and it means anything can happen, so as per specs it's not a bug. Ultimately it's the programmer's mistake for having undefined behavior in his code.
Unfortunately, "it's not a bug, it's a feature!" -- there are long-standing design choices in C/C++ where various circumstances are explicitly designed to yield "undefined" behavior where literally anything goes. I believe the original intent of these are to give the compiler/optimizer more room to speed up the executable. Edit: The 'undefined' clause here is due to invoking a function at address 0, rather than any l…
Globals are always initialized. If no initial value is specified, they’re initialized to zero.
What’s undefined here is calling a function pointer that contains zero. Thus the compiler assumes that it must have been set before being called, and since there’s only one value it could possibly be set to, it must be that value.
Re: Why undefined behavior may call a never-called function
#10Earlier quoted context omitted.
One of the advantages of using Docker! You can safely run this code multiple times and play with it without affecting your machine.
Sure, but you could also replace "rm -rf /" with "id" or something else non destructive. Somebody is going to copy paste that snippet and have a bad day.
I believe "rm -rf /" illustrates the point quite well, better than id. I'm more in the common sense is more common than people give credit and in the situations where that is not the case then rm has built-in protections.
It literally says:
> That is, the compiled program executes “rm -rf /”
The next line following the code. It's not tricking anyone.