6 ms·

> C compilers reserve the right to completely and silently break your program at the faintest whiff of undefined behavior <rant> Please, stop pushing this wron

by pif 10y ago

> C compilers reserve the right to completely and silently break your program at the faintest whiff of undefined behavior <rant> Please, stop pushing this wrong rethoric forward! As soon as there is undefined behavior, it's a bug in the code. There is a problem, and the problem is on the developer's side. I appreciate the effort of compilers to help me get the most performant machine code I can, and I've had enough of people asking them to stop being smart in order to accomodate crappy code. </rant>

wvenable 10y ago
> As soon as there is undefined behavior, it's a bug in the code. I think the emphasis on the original comment should be on the silent part. Nobody is arguing that these aren't bugs in the code; the problem is that you get no help from the compiler or runtime to find them and the damage is more severe than it would be if it simply crashed.
- pif 10y ago
  > the damage is more severe than it would be if it simply crashed. I think I see your point, but you are wrong when you write "simply". Crashing in case of UB is not simple! Actually, ensuring any type of behavior in case of UB is not simple! It requires huge lots of runtime checks, thus you obtain a ridden executable as output. If you want your program to be cuddled in a safe baby box (which is the right thing to want in several cases), then go for an interpreted language, but please let "gcc -O3 -march=..." be what it is: a masterwork coated with magic.
  - wvenable 10y ago
    In the vast majority of cases, concept of Undefined Behavior shouldn't even exist. All behavior should be defined. We have massively powerful machines and the performance advantage mostly doesn't outweigh the potential damage. And other languages, like Rust, even eliminate lot of UB without a lot of overhead. There are exceptions to every rule, of course, but we need to re-evaluate our priorities as times change.
dbaupp 10y ago
A major problem with undefined behaviour and compilers exploiting it is how unforgiving they are: there's no hint to the programmer (unless they explicitly opt in to a sanitiser, which they should, but usually don't) that they have written a bug, the compiler just happily "assumes" that the programmer is flawless and hence the code is exactly what was intended. Blaming the developer for mistakes seems far less productive than understanding that they are inevitable and investing in defences, whether in the form of better tooling for C or languages that fundamentally avoid or restrict the problems C has.
- pif 10y ago
  > the compiler just happily "assumes" that the programmer is flawless In my experience, this is the right thing to do for most applications. Every time a program (ex: compiler) tries to guess what its user (ex: developer) meant, instead of just sticking to the input, there will be problems. In particular, you may help some users in some cases, but you'll prevent other users to get what they have the right to have. > ... seems far less productive ... And maybe it is, but it's not a compiler's business. Use automatic tools, write your own tools, decide coding convention, impose code reviews, but please let the compiler do what it is supposed to do and how it has learned to do in decades of evolution.
  - dbaupp 10y ago
    > Every time a program (ex: compiler) tries to guess what its user (ex: developer) meant, That's one approach to fixing errors, but there's another: tell the programmer that there's an error, and let them decide the best way to fix it. As you say, unsupervised "DWIM" is problematic, and so is a computer program that trusts its inputs absolutely. > And maybe it is, but it's not a compiler's business. What exactly isn't a compiler's business? Helping the programmer write a program that solves their problem? I would say that that is 100% of the compiler's job. It might be that part of the problem is "absolute performance", but that is almost always a secondary concern to correctness... computing the wrong answer (or pwning the user's data) is suboptimal, no matter how fast it happens. C defaults to exploiting everything for performance, rather than defaulting to correctness while also providing opt-in ("dangerous") tools for performance that one can use when necessary.
ekidd 10y ago
djb, who is famous for being an exceptionally talented and careful C programmer, summarized these issues better than I ever could: https://groups.google.com/forum/m/#!msg/boring-crypto/48qa1kWignU/o8GGp2K1DAAJ https://groups.google.com/forum/m/#!msg/boring-crypto/48qa1k... Yes, every time a C program relies on undefined behavior, it's a bug. And as djb observed, virtually all non-trivial C programs contain these bugs. This is the core of my argument. Yes, we could rely on C programmers never making mistakes. But it would be better to design languages with no undefined behavior.
- RUG3Y 10y ago
  As someone that doesn't HAVE to use C, this weirdness is one of the things that makes it interesting to me. I'm sure I'm the exception here, and if I were writing lots of C code for big projects I'd feel otherwise.
- ArkyBeagle 10y ago
  His idea of flagging UB at compile-time is pretty obvious - I have to wonder what the economics are that it hasn't been an emphasis at all, all these years. I do get a facial tick when people say "all significant C programs use (or contain) UB." It's never been necessary and it's always been shameful.

by pif 10y ago

wvenable 10y ago

> As soon as there is undefined behavior, it's a bug in the code. I think the emphasis on the original comment should be on the silent part. Nobody is arguing that these aren't bugs in the code; the problem is that you get no help from the compiler or runtime to find them and the damage is more severe than it would be if it simply crashed.

pif 10y ago
> the damage is more severe than it would be if it simply crashed. I think I see your point, but you are wrong when you write "simply". Crashing in case of UB is not simple! Actually, ensuring any type of behavior in case of UB is not simple! It requires huge lots of runtime checks, thus you obtain a ridden executable as output. If you want your program to be cuddled in a safe baby box (which is the right thing to want in several cases), then go for an interpreted language, but please let "gcc -O3 -march=..." be what it is: a masterwork coated with magic.
- wvenable 10y ago
  In the vast majority of cases, concept of Undefined Behavior shouldn't even exist. All behavior should be defined. We have massively powerful machines and the performance advantage mostly doesn't outweigh the potential damage. And other languages, like Rust, even eliminate lot of UB without a lot of overhead. There are exceptions to every rule, of course, but we need to re-evaluate our priorities as times change.

dbaupp 10y ago

A major problem with undefined behaviour and compilers exploiting it is how unforgiving they are: there's no hint to the programmer (unless they explicitly opt in to a sanitiser, which they should, but usually don't) that they have written a bug, the compiler just happily "assumes" that the programmer is flawless and hence the code is exactly what was intended. Blaming the developer for mistakes seems far less productive than understanding that they are inevitable and investing in defences, whether in the form of better tooling for C or languages that fundamentally avoid or restrict the problems C has.

pif 10y ago
> the compiler just happily "assumes" that the programmer is flawless In my experience, this is the right thing to do for most applications. Every time a program (ex: compiler) tries to guess what its user (ex: developer) meant, instead of just sticking to the input, there will be problems. In particular, you may help some users in some cases, but you'll prevent other users to get what they have the right to have. > ... seems far less productive ... And maybe it is, but it's not a compiler's business. Use automatic tools, write your own tools, decide coding convention, impose code reviews, but please let the compiler do what it is supposed to do and how it has learned to do in decades of evolution.
- dbaupp 10y ago
  > Every time a program (ex: compiler) tries to guess what its user (ex: developer) meant, That's one approach to fixing errors, but there's another: tell the programmer that there's an error, and let them decide the best way to fix it. As you say, unsupervised "DWIM" is problematic, and so is a computer program that trusts its inputs absolutely. > And maybe it is, but it's not a compiler's business. What exactly isn't a compiler's business? Helping the programmer write a program that solves their problem? I would say that that is 100% of the compiler's job. It might be that part of the problem is "absolute performance", but that is almost always a secondary concern to correctness... computing the wrong answer (or pwning the user's data) is suboptimal, no matter how fast it happens. C defaults to exploiting everything for performance, rather than defaulting to correctness while also providing opt-in ("dangerous") tools for performance that one can use when necessary.

ekidd 10y ago

djb, who is famous for being an exceptionally talented and careful C programmer, summarized these issues better than I ever could: https://groups.google.com/forum/m/#!msg/boring-crypto/48qa1kWignU/o8GGp2K1DAAJ https://groups.google.com/forum/m/#!msg/boring-crypto/48qa1k... Yes, every time a C program relies on undefined behavior, it's a bug. And as djb observed, virtually all non-trivial C programs contain these bugs. This is the core of my argument. Yes, we could rely on C programmers never making mistakes. But it would be better to design languages with no undefined behavior.

RUG3Y 10y ago
As someone that doesn't HAVE to use C, this weirdness is one of the things that makes it interesting to me. I'm sure I'm the exception here, and if I were writing lots of C code for big projects I'd feel otherwise.
ArkyBeagle 10y ago
His idea of flagging UB at compile-time is pretty obvious - I have to wonder what the economics are that it hasn't been an emphasis at all, all these years. I do get a facial tick when people say "all significant C programs use (or contain) UB." It's never been necessary and it's always been shameful.