> As I said earlier in this thread, people seem to think that the > standards committee invented something new here in making overflow > undefined, but I don't think that's the case.
I agree with that too. However, it is also the case that between K&Rv1 and the ANSI C standard, there was a language that was a superset of K&Rv1 C and that could be called "Unix C" or "Bell Labs C" where people sort of "understood" what it was, but it was never formally specified anywhere. Most people would view PCC as an operational specification of that language and hence would say that wrapping semantics was part it. That's where a lot of these problems started. > I personally would have thought it more judicious to make it > implementation defined, since I don't like undefined semantics > anywhere in programming languages unless a hugely strong case can be > made that providing or requiring a definition damages code Was the distinction between "undefined" and "implementation defined" well understood in that era? K&Rv2 says that "the behavior is not defined by the language" and then goes on to talk about what "most implementations" do. To me, saying that the "behavior" rather than the "result" is undefined sounds more like what today is called "implementation defined" than "undefined". But the standard indeed didn't copy that language.
