[EMAIL PROTECTED] (Florian Weimer) wrote on 18.06.05 in <[EMAIL PROTECTED]>:
> * Paul Schlie: > > > So in effect the standard committee have chosen to allow any program which > > invokes any undefined behavior to behave arbitrarily without diagnosis? > > > > This is a good thing? > > It's the way things are. There isn't a real market for > bounds-checking C compilers, for example, which offer well-defined > semantics even for completely botched pointer arithmetic and pointer > dereference. > > C isn't a programming language which protects its own abstractions > (unlike Java, or certain Ada or Common Lisp subsets), and C never was > intended to work this way. Consequently, the committee was right to > deal with undefined behavior in the way it did. Otherwise, the > industry would have adopted C as we know it, and the ISO C standard > would have had the same relevance as, say, the ISO Pascal on the > evolution of Pascal. And yet, languages like ISO Pascal *still* define undefined behaviour pretty much the same way C does. They just choose a different set of situations (well, there *is* overlap) to apply it to. Pretty much all languages which allow access to "the bare metal" need this escape clause, because making a program safe in that context pretty much requires the compiler to solve the halting problem or equivalent - and we can't do that. The alternative is putting enough padding between the program and the metal to enable the compiler and runtime system significantly more control - and, of course, giving the programmer significantly *less* control. For example, there won't be any type-punning in such a language. It's a very different trade-off. MfG Kai
