Liste des Groupes | Revenir à c arch |
On 9/2/2024 8:36 AM, MitchAlsup1 wrote:No, the error in the code caused the code to break. You don't get to blame the compiler if you write rubbish. You get to /thank/ the compiler if it has helpfully added an instruction to cause the program to stop abruptly with a UD2 instruction.On Mon, 2 Sep 2024 5:55:34 +0000, Thomas Koenig wrote:I had just recently discovered that newer versions of GCC will cause code to break if it is missing a return value in C++ mode.
>George Neuner <gneuner2@comcast.net> schrieb:>
>I'm not going to argue about whether UB in code is wrong. The>
question I have concerns what to do with something that explicitly is
mentioned as UB in some standard N, but was not addressed in previous
standards.
>
Was it always UB? Or should it be considered ID until it became UB?
Can you give an exapmple?
Memcopy() with overlapping pointers.
So:If your compiler tells you you are doing something stupid, and you ignore it, I really don't think you can claim "the compiler broke my code".
int Foo() { }
Will (in theory) cause the program to crash when called (emitting a 'UD2' instruction), except in WSL it seems this doesn't quite work correctly (the UD2 doesn't result in an immediate crash), and the program seemingly instead "goes off the rails and crashes at a later point" (GCC omits the epilog when it does this, and seemingly control flow then goes into whatever function follows in the binary, crashing when that function tries to return seemingly by branching to an invalid address or similar).
This was mostly effecting "init" functions in my Verilator test benches...
Well, that, and a more inconsistent variant, where if one declares struct fields as 8 and 3 bytes and then strncpy's 11 bytes into the combined field, it may also insert a UD2 and skip emitting the following code.
...
But, yeah, that was annoying...
Les messages affichés proviennent d'usenet.