On C-optimizing compilers removing code that has undefined behavior
1–10 of 71 posts
Re: On C-optimizing compilers removing code that has undefined behavior
#2Perhaps the committee has been infiltrated by the Rust Evangelism Strikeforce?
Re: On C-optimizing compilers removing code that has undefined behavior
#3What 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?
Re: On C-optimizing compilers removing code that has undefined behavior
#4What 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?
Itanium. (Not very common use, but it's out there.)
Re: On C-optimizing compilers removing code that has undefined behavior
#5> 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.
Re: On C-optimizing compilers removing code that has undefined behavior
#6I get a database error... Here's an archived copy:
Re: On C-optimizing compilers removing code that has undefined behavior
#7> 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.
Re: On C-optimizing compilers removing code that has undefined behavior
#8Perhaps the committee has been infiltrated by the Rust Evangelism Strikeforce?
I wouldn't be surprised if the Erlangs had something to do with it
Re: On C-optimizing compilers removing code that has undefined behavior
#9> 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 compilation error, I am okay with it.
Re: On C-optimizing compilers removing code that has undefined behavior
#10What 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.