If the terminal is a native view don’t you lose the benefit of the terminal contents being an emacs buffer? I mean things like yanking from it, macros etc, emacs is your scroll back, navigating to files in program output etc?

score 1 · canonical

So we agree that UB has nothing to do with cross platform compatibility.

I don’t think we do.

an argument against any implementation defined behavior,

Without committing to the idea that there are never overriding reasons to have implementation defined behavior I agree this is an argument against it. All other things being equal in a language meant to be portable I would rather have universally defined behavior over implementation defined behavior.

There is absolutely no difference in the degree of difficulty in avoiding all UB and avoiding all IDB: the logic required to avoid invoking UB for any given operation is that same logic required to avoid IDB.

While I think difficulty is a factor, a bigger consideration here is the requirements placed on the program author. They are obligated to provide a program with no UB, they are not obligated to avoid IDB, whether or not it is a good idea.

There is not difference in cross platform compatibility: the same incompatible code exists in both cases

In the ontology of C the UB version of the “incompatible code” actually does not exist.

In what way does labeling something like integer overflow UB rather than IDB make writing portable code easier?

For implementors they are removed the burden of documenting the implementation defined behavior and the burden of considering the case. They emit an add instruction and call it quits. For program authors they are removed the burden of needing to familiarize themselves with the IDB of the various targets their code made be compiled under, they just don’t write code with overflow and it works everywhere.

In what way does labeling something UB rather than IDB make reasoning about code behavior easier?

A program with IDB has multiple possible meanings all of which must be considered. A program with UB is excluded from needing to be reasoned about. It makes it easier the same way invalid syntax makes it easier.

in what way does labeling something UB make the language better than it would be if it was instead labeled IDB?

I don’t know that it does make the language better. It may be a good strategy to increase the number of implementations by making implementing it easier at the expense of making the language worse for its users. A lot of UB in C is just taking things off the plate of the implementor.

If the concern is actually cross platform compatibility, then why not simply define the behavior?

In general that would be my preference, as much defined behavior as possible.

score 1 · canonical

UB has nothing to do with supporting different hardware behaviour. At all.

Consider your example of signed integer overflow. If this were implementation defined behavior conforming, correct C programs that relied on the implementation specific behavior (wraparound, saturation, trapping, whatever) would not be portable to different hardware that had different behavior.

Since it is undefined behavior, conforming correct C programs are correct with respect to all hardware.

score 1 · canonical