On Sun, Feb 27, 2022 at 9:19 PM Segher Boessenkool <segher@xxxxxxxxxxxxxxxxxxx> wrote: > > Requiring to annotate every place that has UB (or *can* have UB!) by the > user is even less friendly than having so much UB is already :-( Sure, but I did not suggest to annotate every place -- at least not in C. What I said is that in cases like your division by zero example, there is no one-fits-all solution. For instance, for integer arithmetic, leaving the choice (e.g. wrapping, saturating, unchecked...) to the user is a better approach. > You need a VM like Java's to get even *close* to that. This is not the > C target: it is slower than wanted/expected, it is hosted instead of > embedded, and it comes with a whole host of issues of its own. One of > the strengths of C is its tiny runtime, a few kB is a lot already! > > I completely agree that if you design a new "systems" language, you want > to have much less undefined behaviour than C has. But it is self- > delusion to think you can eradicate all (or even most). Nobody is suggesting to remove "all UB" in that sense or to use VM-supported languages. However, you can """eradicate all UB""" in a sense: you can offer to write most code in a subset that does not allow any potential-UB operations. This can even be "all" code, depending on how you count (e.g. all application code). Obviously, you still need the unchecked operations to implement the safe APIs. This is why I mentioned them. > And there are much bigger problems in any case! If you think that if > programmers could no longer write programs that invoke undefined > behaviour they will write much better programs, programs with fewer > serious functionality or security problems, even just a factor of two > better, well... Actually, according to several reports from Google, Microsoft, etc., it _is_ the biggest problem (~70%) when talking about security bugs. So it is a good bet that it will translate into "better" programs, at least on that axis, unless it is showed that removing UB somehow increases the rate of other errors. As for functionality problems, there are several ways to improve upon C too, though it is harder to show data on that. Cheers, Miguel
