3 ms·

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

by 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.

by dbaupp 10y ago

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.