Perhaps the committee has been infiltrated by the Rust Evangelism Strikeforce?
Could you please stop violating the guidelines?
On C-optimizing compilers removing code that has undefined behavior
61–70 of 71 posts
Re: On C-optimizing compilers removing code that has undefined behavior
#62Earlier quoted context omitted.
Still, making the compiler do whatever the hell it wants because "hey it's undefined behavior so we have the license to" is just as idiotic. Make the compilation fail and then add a flag to override for those who feel extra smart.
The compiler is not doing "whatever the hell it wants". It chooses an interpretation of the undefined behavior and then optimizes based on that. Of course, if the programmer had something else in mind, they will be surprised about the result; but it's their fault for not being precise enough. So why make reads of uninitialized values undefined at all? Consider code like this: uint64_t x; // Will be initialized later…
"...It chooses an interpretation ... But the compiler was just working from what it knew, and under the assumption ..."
Why should it do that? Just stop compiling and yell at the user, demanding proper code. I'd not let the code you gave as an example pass any review because it is not clear what the author intended.
Re: On C-optimizing compilers removing code that has undefined behavior
#63The author quotes an article referring to using uninitialized memory for additional entropy and that article cites [10]. Let me just say: DON'T do that, ever. Uninitialized memory is rarely random. If you're lucky, it's quasi-constant because your own program always writes something else to it before. Worst case an attacker manages to write something to that memory before you read it, thereby controlling part of your…
Actually some well know researchers are quite known to be against UB, but C compiler writers don't seem to be willing to listen to them. https://blog.regehr.org/archives/1054
I can relate to that. I guess undefined behavior makes it somewhat harder to write correct software. I've definitely read someone make the same point.
The problem is, you can't always know if (for example) you're reading from an uninitialized variable, unless you run the program with the possibly infinite number of valid inputs, thereby also solving p != np.
In my opinion, undefined behavior is what we have and we had enough time to learn how to deal with it. If at all possible, compilers should be able to detect UB, so I can use compile flags to make UB an error. Changing the language to "define" undefined behavior, might turn it into unexpected behavior and I wouldn't like that. At least we've learned the lesson with newer languages.
Re: On C-optimizing compilers removing code that has undefined behavior
#64Earlier quoted context omitted.
Actually some well know researchers are quite known to be against UB, but C compiler writers don't seem to be willing to listen to them. https://blog.regehr.org/archives/1054
I can relate to that. I guess undefined behavior makes it somewhat harder to write correct software. I've definitely read someone make the same point. The problem is, you can't always know if (for example) you're reading from an uninitialized variable, unless you run the program with the possibly infinite number of valid inputs, thereby also solving p != np. In my opinion, undefined behavior is what we have and we ha…
> At least we've learned the lesson with newer languages.
The thing is, we already knew that from older languages as well. C's UB is a consequence of the people involved in ANSI C89 not wanting to fully define the language, like the other languages were doing.
I think the lesson is that "Performance trumps correctness" is the wrong path to follow, specially since not everyone using C is a 10x coder that always makes use of best practices.
Re: On C-optimizing compilers removing code that has undefined behavior
#65> The programmer has clearly attempted to set x[0]=0 Then why not just write it like that? This is like deliberately shooting yourself in the foot and complaining that your shotgun works.
That was just an example but I'm starting to have horror visions: imagine you have a struct with some gaps because of alignment, and you read it as chars (which you are supposed to can and must do to get the representation) after having properly initialized all its fields. You might hit an UB just by doing that, maybe not according to the standard for obscure reasons (I hope so), but the probability you are going to…
The contents of padding are unspecified after a write; reading it is not UB. Essentially: the padding belongs to the member, and after you initialized the member the padding is initialized as well (you just don't get any guarantee of the value).
This is the reason why padding for wire formats has to be made explicit and be explicitly initialized, otherwise the compiler is free to generate code packing bible quotes into the padding.
Re: On C-optimizing compilers removing code that has undefined behavior
#66Earlier quoted context omitted.
That was just an example but I'm starting to have horror visions: imagine you have a struct with some gaps because of alignment, and you read it as chars (which you are supposed to can and must do to get the representation) after having properly initialized all its fields. You might hit an UB just by doing that, maybe not according to the standard for obscure reasons (I hope so), but the probability you are going to…
The contents of padding are unspecified after a write; reading it is not UB. Essentially: the padding belongs to the member, and after you initialized the member the padding is initialized as well (you just don't get any guarantee of the value). This is the reason why padding for wire formats has to be made explicit and be explicitly initialized, otherwise the compiler is free to generate code packing bible quotes in…
> The contents of padding are unspecified after a write; reading it is not UB.
Ok so like I said: "depending of the [effective] type maybe reading an uninitialized byte will be UB, or maybe not, depending of how that byte was in a field of a type or just alignement... "
If I understand correctly this is so insane (to treat those that are UB in that context as effectively UB) that I still have no word.
I absolutely do not want to use a compiler made by people who consider that that situation is OK or even just tolerable for potential gains, regardless of the speedup you could obtain (even at 1000%, I just don't want it -- the risks are way too high)
EDIT: I reread and I think I misunderstood. This is not as bad as I thought, but this is extremely complex and I guess compiler bugs will happen (or have already?) in this area. [ Also what is the relationship with extensions? (like pre-standard or even standard explicit extra alignments...) ]
Re: On C-optimizing compilers removing code that has undefined behavior
#67Earlier quoted context omitted.
The contents of padding are unspecified after a write; reading it is not UB. Essentially: the padding belongs to the member, and after you initialized the member the padding is initialized as well (you just don't get any guarantee of the value). This is the reason why padding for wire formats has to be made explicit and be explicitly initialized, otherwise the compiler is free to generate code packing bible quotes in…
> The contents of padding are unspecified after a write; reading it is not UB. Ok so like I said: "depending of the [effective] type maybe reading an uninitialized byte will be UB, or maybe not, depending of how that byte was in a field of a type or just alignement... " If I understand correctly this is so insane (to treat those that are UB in that context as effectively UB) that I still have no word. I absolutely do…
Actually, it's even more ridiculous than that. Reading with a char * is UB. Reading with an unsigned char is not. Why? Because the C90 standard made it impossible to write memcpy in C so the committee added a hack for unsigned char .
Re: On C-optimizing compilers removing code that has undefined behavior
#68I am 100% in agreement with the C standard committee on this one. Treating all use of uninitialized memory as undefined behavior is a reasonable limitation that gives compiler writers a great deal of flexibility to improve performance. If the only loss is the ability to use uninitialized memory as a source of entropy for random number generators, then that is an incredibly low price to pay for the increased performan…
They are improving performance in what way? My compiler: read input; emit nop, improves performance too.
Re: On C-optimizing compilers removing code that has undefined behavior
#69Earlier quoted context omitted.
you do in my opinion, i don't understand why UB is so foundamental to C, in this case woudn't a compiler warnig or error be better?
UB is pretty damn fundamental to C. Not many people realize it though. It's the fundamental difference between C and C++ compared to Python or C# or Java or Rust or whatever.
Wrong. Indeterminate is fundamental to C. UB is a hack.
Re: On C-optimizing compilers removing code that has undefined behavior
#70Earlier quoted context omitted.
UB is pretty damn fundamental to C. Not many people realize it though. It's the fundamental difference between C and C++ compared to Python or C# or Java or Rust or whatever.
Wrong. Indeterminate is fundamental to C. UB is a hack.
Cool, you've convinced me now.