You don't get to write C and complain about UB breaking your code at the same time.
On C-optimizing compilers removing code that has undefined behavior
11–20 of 71 posts
Re: On C-optimizing compilers removing code that has undefined behavior
#12> 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.
While I fully agree with you, but I will still like C to be as self explanatory as possible. C is the closest language for which one doesn't need to know the standard to understand it, at least the standardised C. I think it should be one of the biggest aim of C to let the language as it is(except the standard library). This change creates something that might not be expected by some. If this is replaced by an compil…
> but I will still like C to be as self explanatory as possible.
C is not self-explanatory at all and without good knowledge of the standard anyone will write broken code that will fall apart sooner or later. C is not a simple language, nor one with simple semantics. Without knowledge of the standards it is essentially not possible to write portable C code.
Re: On C-optimizing compilers removing code that has undefined behavior
#13> 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.
Exactly. A compiler cannot guess what a programmer intended, but has to stick to the language semantics. Also, the article goes on to argue that uninitialized memory is used to seed random generators, which is generally undefined behavior. I don't think this should be a valid use-case.
[deleted]
Re: On C-optimizing compilers removing code that has undefined behavior
#14> 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.
The problem is that the language allows this code and the compiler accepts it.
If the code really does make no sense, then why not disallow it or capture it with a compiler warning?
Instead the optimizer is to silently remove the code.
Isn't it possible that the programmer knows something that the optimizer is unaware of?
Re: On C-optimizing compilers removing code that has undefined behavior
#15The 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 seed. The cited article also recommends to "In short, just don’t use uninitialized memory for more randomness."
Really, exploiting undefined behaviour in crypto code is a bad idea, and you should make sure you compile with flags that at least catch the most common cases, like the one mentioned in the post.
[10] http://kqueue.org/blog/2012/06/25/more-randomness-or-less/
Re: On C-optimizing compilers removing code that has undefined behavior
#16> 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.
Agreed. A modern compiler will pick the optimal assembly (most of the time!)
That said, I feel like C often lacks the expressiveness to properly define intent and allow the compiler to optimise well.
Re: On C-optimizing compilers removing code that has undefined behavior
#17I 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 performance.
Re: On C-optimizing compilers removing code that has undefined behavior
#18What CPUs in common use still have trap representations? Are there other reasons why reading from an indeterminate value can't give an arbitrary but well-defined result?
x86, in the form of signalling NaNs, when the appropriate fpu flag is set. Some languages feel it's better to fail a computation early and loudly than to silently proceed with a cascade of non-signalling nans possibly getting as far as the screen or database. Delphi for one. C will see this if it's in a library linked with code in such a language.
Aren't signaling NaNs defined to trigger a floating point exception, not invoke undefined trap-representation behavior?
EDIT: I found this proposal (http://www.cl.cam.ac.uk/~pes20/cerberus/n2091.html) which has some discussion about existing trap representations (including whether to consider signaling NaNs to be trap representations). The conclusion seems to be that segmented pointers on the Motorola 68k are the only place trap representations are truly necessary -- maybe it's time to just remove them.
Re: On C-optimizing compilers removing code that has undefined behavior
#19> 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.
Exactly. A compiler cannot guess what a programmer intended, but has to stick to the language semantics. Also, the article goes on to argue that uninitialized memory is used to seed random generators, which is generally undefined behavior. I don't think this should be a valid use-case.
So go use rust and leave C for those who think it should.
Re: On C-optimizing compilers removing code that has undefined behavior
#20I 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…
Then why isn't the code being disallowed? Why is it being silently removed in the middle of the night through an optimization back door?