> It wouldn't be an example of undefined behavior as given at https://en.wikipedia.org/wiki/Undefined_behavior : "undefined behavior (UB) is the result of executing computer code that does not have a prescribed behavior by the language specification" because Python prescribes that behavior.

But the C spec doesn't prescribe any behavior in this case, and the code that is running in this case is C, not Python! It was written in C, it was compiled by a C compiler -- it's C! Whether or not the behavior is undefined for anything a C program does is determined by the C spec only. The Python spec is not relevant. Any C program that overflows an int has done something undefined, whether or not that C program happens to be a Python implementation.

The C specification is irrelevant.

The Python specification defines what the implementation is supposed to do. It happens that the implementation doesn't comply with the specification. That doesn't mean the Python specification is undefined, it means the implementation is in error.

Remember too that the actual implementation is a binary. The C compiler converted the C code into that binary, but in theory it could have been generated manually, as a byte-for-byte equivalent, with C completely out of the picture.

Would you still say it's "undefined behavior" if there were no C compiler? How do you tell the difference in the binaries?

By that logic, you couldn't say anything is ever undefined when it happens in binary machine code, or what spec should apply -- you couldn't say it is C or that it is Python. That level of reductionism doesn't get you anywhere.

Do you not realize that that reductionism is exactly why I don't like your definition of "undefined behavior"?

You are using a non-standard definition of "undefined behavior". In common use, "undefined behavior" is only meaningful relative to a language specification, not an implementation.

Why do you think you are using the common definition when you include implementation bugs as part of UB?

Your definition leads to a serious contradiction:

Case 1: A C program overflows an int (which is listed as an undefined behavior in the C spec). Under your definition, and pretty much any other, that program has executed code that results in undefined behavior.

Case 2: A C program overflows an int. That C program happens to be the Python interpreter. Under your definition, based on your responses to previous comments, that did not result in undefined behavior, but was an implementation bug instead.

There is no difference between case 1 and case 2. They are both C programs, so the spec for C determines what is undefined behavior for them. They both did the same thing. Either both are executing code that results in undefined behavior, or neither is.

Case 2 is also an example of an implementation bug if it affects the result of the Python code running in the interpreter.

There is no contradiction. There are two specifications, the C language specification and the Python language specification.

Programs written in Python follow the Python language specification.

When run in CPython, the implementation follows the C language specification.

If the implementation uses C UB, which causes it to be out of compliance with the Python specification, then it is both undefined behavior for C and a failure to follow defined behavior for Python.

It is not undefined behavior for Python.

I have said multiple times that I don't like how your non-standard definition mixed the two together. It is no longer interesting to come up with new ways to restate my statement.

> If the implementation uses C UB, which causes it to be out of compliance with the Python specification, then it is both undefined behavior for C and a failure to follow defined behavior for Python.

That's true, but it's not what you said. You said "the C specification is irrelevant" when I brought up bugs in the C code in CPython, and you said they were implementation bugs but not UB, because the Python spec doesn't define them as UB -- even though the code we were talking about was C! In other words, case 2 in my previous comment.

Now you say "When run in CPython, the implementation follows the C language specification," and "If the implementation uses C UB, which causes it to be out of compliance with the Python specification, then it is both undefined behavior for C and a failure to follow defined behavior for Python."

Those arguments contradict each other. Which one do you believe?