In article <110ghmv$21vi3$1@dont-email.me>,I think it is important for tools to be helpful, and it's fine to complain if a tool is being directly unhelpful - or ask for improvements when you think it could be better.
David Brown <david.brown@hesbynett.no> wrote:[snip]Eh...I think those people have a point.
As for my '"modern compilers are evil" crowd' comment, there are people
(not anyone involved in this discussion) who really do fall into that
camp. I've seen people who are experienced and respected developers
make all sorts of accusations to compiler developers, claiming they are
only interested in high scores on synthetic benchmarks and directly
insulting their motivations and integrity, blaming them for "breaking"
their code that relied on the effects of some kinds of UB. It is always
frustrating when you have code that works fine with one compiler
version, but using another compiler results in failure due to UB in your
code - especially if writing correct code gives inefficient results with
the first compiler. And it's fine to say you'd be happier if a
particular thing that is UB in C were not UB - but it is unreasonable to
blame compiler developers for implementing the language as it is defined.
Note, I don't think that "modern compilers are evil" (I mean,
wow, that's a strong word) and I certainly do not think it is
appropriate to malign the people who write them personally over
what one does with code.
But I _do_ think it is fair to say that UB is very easy to fallIt can certainly happen, yes. And I fully sympathise on these few occasions when changes to the standard has meant that code that previously had defined behaviour, now has different or undefined behaviour. (However, I think that for some kinds of code, programmers could be better at specifying exactly what standards their code requires, and the standards they use when compiling code.)
into in C, that programs that have worked correctly (insofar as
their intended behavior as written) for years can suddenly fail
because latent UB is treated differently in a point revision of
a compiler, and that that (as you point out) can be incredibly
frustrating for the authors.
But it is important to realise that if you write code with UB, it is /your/ mistake - not the mistake of the compiler developers, or the mistake of the standards authors. Compiler vendors can (and do!) try to help programmers find their mistakes - experience shows, however, that many programmers reach first for bug report forms or complaints in forums before compiler tools like sanitisers or even enabling warnings on their builds.
Programming in C is a cooperative effort - including the standards authors, the compiler vendors, and the C programmers. Each group can try to help the others, but each is ultimately responsible for their own part.
Regehr called out a dichotomy with UB: programmers using aI think Regehr has made some good points in his writings, but I do not agree with him on everything.
language hate it; compiler writers love it.
As a programmer, I am a fan of the concept of UB. I am quite happy with the idea that operations have a pre-condition, and that if there is no "right answer" for a given input, I should not provide that input. I prefer that signed integer arithmetic overflow is UB, and do not want it to be wrapping or have some other semantics - to me, it is far clearer that way. If I have UB in my code, it's a bug - no different from any other bug I might make.
It is the case that in C, there are some kinds of UB that can be quite subtle. However, you rarely need to risk meeting them. Yes, there are pitfalls - don't go near them, and they don't matter.
However, it is unfortunately the case that sometimes avoiding UB can be costly in performance terms. An example would be if you have need of type-punning - perhaps you have a float in memory and you want to access it as an uint32_t for some reason. Casting a float * to an uint32_t * and using that new pointer is UB. Some compilers will nonetheless generate the code you want after such a cast. Some compilers might not, depending on details of the rest of the surrounding code, because it is UB. A non-UB solution would be to use memcpy(), or a type-punning union. For highly optimising compilers, that's fine - the code generated by gcc or clang for a memcpy() here is likely to be as efficient as you could get - directly reading the float from memory to an integer register. For other compilers, however, you might get a call to a memcpy() library function in an external DLL, taking orders of magnitude more cycles. What is the poor programmer to do? Write code that is portable and correct, but very slow with some implementations? Write code that "cheats" and is efficient on some implementations but might not give the desired results on others? Use pre-processor monstrosities to detect different compilers and adapt accordingly? That is what I see as the biggest issue resulting from compiler optimisation based on UB. I don't know what the "best" answer here is.
Here's my own vignette: I was chatting with a friend who worksI too want a language with well-defined semantics that can be aggressively optimised. But I do not see UB as a hinder to that. I am happy knowing that I cannot divide by 0, or find the square root of a negative number (in the real domain). I am happy knowing that I cannot add two ints if their sum overflows the range of their type, and that I cannot call a function with a different number or type of parameters than its definition. I have a great deal of difficulty seeing how things could be any different, other than in a managed language with significant overhead from run-time checks - and that goes against the "aggressively optimised" requirement.
on LLVM and clang some time ago. I said, "I don't want UB" and
he replied, "no, you really do." I asked him what he meant and
he responded that I wanted a compiler that is capable of
optimizing my program; "sure, but I still don't want UB." We
went on for a bit, and it became clear that he saw UB as _the_
vehicle for unlocking optimization.
I realized that we were not speaking the same language _at all_.
He and I both wanted a language where we could write programs
that yield efficient object code. He saw UB as essential for
that; but what I want is a language with well-defined semantics
that can be aggressively optimized.
Having "well-defined semantics" does not mean the language should accept anything that happens to fit the syntax and grammar rules, or that all functions and operations should give a defined result for all inputs. It means that the set of valid inputs is clearly defined, along with the outputs and effects you get when the inputs are valid.
(There are plenty of points in the C standards where the wording could make the semantics clearer, or where the range of input values could easily have been larger - I am not suggesting C is as well-defined as it could reasonably be.)
That, I think, is the tension: there was a fundamental breakdownCommunication between the separate parties is always an issue, and it is easy for it to be a one-way street with a language standards committee dictating the rules with little attention to feedback, then compiler vendors following these rules without listening to the users.
in communication between the users of the language, and those
defining and implementing it. My subjective sense is that in
the past few years things are getting somewhat better, but it is
hard to evolve something as critical and widely used as C.
A challenge here, perhaps, is that users are a very diverse group. How much should compiler vendors cater for those that put a lot of effort into correctness and want top efficiency, or those that are less knowledgable about the language but want to avoid the consequences of their mistakes? What about those working with old code written for different compilers with different unwritten rules? It is not easy to please everyone.
I think that is a good way to handle the situation. In my projects, I do not normally upgrade or change toolchains. While I think the risk of UB is small in my own code, small does not mean non-existent. And for my work, generated code that behaves correctly in terms of C semantics but has different execution times or code size might also be an issue - so changes in toolchains mean a lot of extra testing and qualification. In addition, for some microcontrollers the toolchains have relatively small user bases and consequently higher risks of unknown bugs in the toolchains themselves. Sometimes there are also implementation-specific features that change between versions (though that is less of an issue these days).I am not in any way saying that critics of aspects of C (the language,The kernel I am working on has about 5 million lines of code.
the standards, or compiler implementations) should be dismissed or
despised - merely that the example of loop elimination leading to UB and
unexpected results is regularly used as "evidence" by those that hold
extreme positions about C, despite it being very unrealistic for the
issue to cause problems in real coding practice.
That code has been evolving for 40 years; some of it predates
the ISO standards and even the ANSI standard. It has been
updated for newer compilers, sure, but in some places the
treatment is surface-level: using ISO-style function prototypes
and definition syntax, for example. But deep problems remain in
parts, and contraints on engineering resources couple with
economic and business pressures so that it's not going to get
cleaned up any time soon. I'm sure there is UB in it; in fact,
I know there is. But them's the breaks; and yet, customers are
using it in production. Because of this, upgrading toolchains
is laborious and complex, and takes a lot of time, and new
compilers are (rightly) viewed with suspicion. That is not a
great situation, but I don't think anyone is angry at the
compiler people over it.
And just as it's not acceptable to blame compiler writers forBeing dead does not resolve you of the responsibility - the person that wrote the code with UB is the person who wrote the code with the UB, just like any other bugs. That person wrote the code with the error. It might not be fair to hold it against them - there are a great many possible reasons why it was not their fault (typically management is more at fault than the coders!). And placing blame is rarely a useful exercise - usually it does not matter where the bugs came from, only that they are there and need to be fixed or worked around.
implementating the language as it is defined, it's not really
acceptable to blame programmers either; some of the people who
put the UB there are (literally) dead, and there's just not
enough time in the day to go clean it all up. I wish there was
more compassion for that.
As said earlier, C is what it is. I suspect that it willAgreed.
continue to make incremental improvements, but we're basically
stuck with what we have.
- Dan C.
Les messages affichés proviennent d'usenet.