6 ms·

A language with undefined behavior is not suitable for new code in 2016 if you have alternatives.

twblalock 10y ago
Python has undefined behavior because it's implementations are written in languages that do. Every implementation of it is written in a language with undefined behavior such as C, or in languages which are themselves implemented in languages with undefined behavior (e.g. Jython, which runs on the JVM, which is written in C and C++). There is no guarantee that an implementation of Python is bug-free, so there is no guarantee that any Python problem is free of undefined behavior. So, if you write a Python library in C or in Python, you'll have undefined behavior either way. Undefined behavior is not a good criteria for choosing which language to use.
- dalke 10y ago
  I think you have mixed multiple definitions of "undefined behavior". A language can say that certain operations are undefined, like reference NULL in C. What of the Python language is undefined? (Some things, like garbage collection, are implementation defined. That is different.) Even if a language contains undefined behavior, a program written in that language can avoid the undefined operations. What of the Python implementations use or depend on undefined operations in the lower-level language? An implementation can also be flawed. But that's not "undefined behavior" but non-conformant behavior. "A bug", in the vernacular. According to your definition, is there any language that doesn't have undefined behavior? After all, even the hardware can have flaws and undefined behavior, so to mix metaphors, it's all a house of cards built upon sand.
  - twblalock 10y ago
    > According to your definition, is there any language that doesn't have undefined behavior? After all, even the hardware can have flaws and undefined behavior, so to mix metaphors, it's all a house of cards built upon sand. That's correct, and it's not pedantic to point that out. It proves that undefined behavior is not a useful criteria for choosing which language to use. But even if we accept your more restricted definition of what constitutes undefined behavior, we still must accept that any language that is implemented in C could possibly exhibit any of C's undefined behavior. Therefore, writing a Python library in Python instead of C cannot help you avoid C's undefined behavior. It might prevent you from introducing more undefined behavior, but that's not the same as avoiding it entirely -- if the implementation is written in C, then that ship has sailed.
    - dalke 10y ago
      I now realize I did not understand your original comment. Thank you for the clarification. I don't agree with how you use "undefined behavior", but it's appropriate for the OP's context.
      - twblalock 10y ago
        I don't think my definition is different from the common one. I agree that undefined behavior is behavior that the spec for the language says is undefined. Pretty much every language has some undefined behavior. That undefined behavior can be invoked intentionally, or because of bugs. C has a lot of undefined behaviors. Even simple addition can result in an undefined behavior because int overflow is undefined. Any C program that takes numbers as input (via the shell, or FFI, or whatever) and adds them together can exhibit undefined behavior. Null pointer dereferences are also undefined, and pretty much any C program of reasonable complexity can encounter those, in the form of bugs. A bug in hardware can also cause these undefined behaviors to be invoked -- for example, a friend of mine who does embedded programming had some null pointer dereferences or something like that because the hardware did not set a value when he told it to set the value. Null pointer dereferences are undefined, and if they happen because of hardware bugs, that is a case of hardware causing undefined behaviors to happen. It would not be reasonable to say they were not undefined behavior simply because they were caused by hardware instead of programmer error. The fact that it happened at all is what matters, not what caused it. Even if a language does not have any undefined behaviors whatsoever, that's not the end of it. If a program in that language interacts with other programs that do have undefined behavior, such as C programs, it could potentially trigger or be affected by undefined behaviors in those other programs. If that happens, it's not reasonable to say that it was not undefined behavior simply because it happened in a piece of code in a different language. (So, if the result of running a Python program is affected by undefined behavior in the C implementation of Python, that program has undefined behavior -- even if the Python code does not. The undefined behavior is C's, not Python's -- but it happens because of running the Python code, which caused the C code to run.) In other words, any invocation of code that causes undefined behavior to happen -- whether it is intentional, or caused by a software bug, or even caused by a hardware bug -- counts.
  - DonHopkins 10y ago
    Reports that say that something isn't defined are always interesting to me, because as we define, there are defined undefines; there are things we define we define. We also define there are defined undefines; that is to say we define that there are some things we do not define. But there are also undefined undefines – the ones we don't define we don't define. And if one looks throughout the history of our language and other free languages, it is the latter category that tend to be the non-conformant ones.
- pjc50 10y ago
  > There is no guarantee that an implementation of Python is bug-free, so there is no guarantee that any Python problem is free of undefined behavior. The implementation being buggy does not mean that the behaviour is undefined in the spec.
  - twblalock 10y ago
    Which spec? The one for Python, or the one for C? It's entirely possible that executing a Python program could cause C code in the Python interpreter, or C code called via FFI, to do something that the C spec defines as undefined behavior. That could affect the result of the Python program. If that happened, it would not be reasonable to say that the Python program did not have undefined behavior -- even if nothing in the Python code was undefined according to the Python spec.

Python has undefined behavior because it's implementations are written in languages that do. Every implementation of it is written in a language with undefined behavior such as C, or in languages which are themselves implemented in languages with undefined behavior (e.g. Jython, which runs on the JVM, which is written in C and C++). There is no guarantee that an implementation of Python is bug-free, so there is no guarantee that any Python problem is free of undefined behavior. So, if you write a Python library in C or in Python, you'll have undefined behavior either way. Undefined behavior is not a good criteria for choosing which language to use.

dalke 10y ago
I think you have mixed multiple definitions of "undefined behavior". A language can say that certain operations are undefined, like reference NULL in C. What of the Python language is undefined? (Some things, like garbage collection, are implementation defined. That is different.) Even if a language contains undefined behavior, a program written in that language can avoid the undefined operations. What of the Python implementations use or depend on undefined operations in the lower-level language? An implementation can also be flawed. But that's not "undefined behavior" but non-conformant behavior. "A bug", in the vernacular. According to your definition, is there any language that doesn't have undefined behavior? After all, even the hardware can have flaws and undefined behavior, so to mix metaphors, it's all a house of cards built upon sand.
- twblalock 10y ago
  > According to your definition, is there any language that doesn't have undefined behavior? After all, even the hardware can have flaws and undefined behavior, so to mix metaphors, it's all a house of cards built upon sand. That's correct, and it's not pedantic to point that out. It proves that undefined behavior is not a useful criteria for choosing which language to use. But even if we accept your more restricted definition of what constitutes undefined behavior, we still must accept that any language that is implemented in C could possibly exhibit any of C's undefined behavior. Therefore, writing a Python library in Python instead of C cannot help you avoid C's undefined behavior. It might prevent you from introducing more undefined behavior, but that's not the same as avoiding it entirely -- if the implementation is written in C, then that ship has sailed.
  - dalke 10y ago
    I now realize I did not understand your original comment. Thank you for the clarification. I don't agree with how you use "undefined behavior", but it's appropriate for the OP's context.
    - twblalock 10y ago
      I don't think my definition is different from the common one. I agree that undefined behavior is behavior that the spec for the language says is undefined. Pretty much every language has some undefined behavior. That undefined behavior can be invoked intentionally, or because of bugs. C has a lot of undefined behaviors. Even simple addition can result in an undefined behavior because int overflow is undefined. Any C program that takes numbers as input (via the shell, or FFI, or whatever) and adds them together can exhibit undefined behavior. Null pointer dereferences are also undefined, and pretty much any C program of reasonable complexity can encounter those, in the form of bugs. A bug in hardware can also cause these undefined behaviors to be invoked -- for example, a friend of mine who does embedded programming had some null pointer dereferences or something like that because the hardware did not set a value when he told it to set the value. Null pointer dereferences are undefined, and if they happen because of hardware bugs, that is a case of hardware causing undefined behaviors to happen. It would not be reasonable to say they were not undefined behavior simply because they were caused by hardware instead of programmer error. The fact that it happened at all is what matters, not what caused it. Even if a language does not have any undefined behaviors whatsoever, that's not the end of it. If a program in that language interacts with other programs that do have undefined behavior, such as C programs, it could potentially trigger or be affected by undefined behaviors in those other programs. If that happens, it's not reasonable to say that it was not undefined behavior simply because it happened in a piece of code in a different language. (So, if the result of running a Python program is affected by undefined behavior in the C implementation of Python, that program has undefined behavior -- even if the Python code does not. The undefined behavior is C's, not Python's -- but it happens because of running the Python code, which caused the C code to run.) In other words, any invocation of code that causes undefined behavior to happen -- whether it is intentional, or caused by a software bug, or even caused by a hardware bug -- counts.
- DonHopkins 10y ago
  Reports that say that something isn't defined are always interesting to me, because as we define, there are defined undefines; there are things we define we define. We also define there are defined undefines; that is to say we define that there are some things we do not define. But there are also undefined undefines – the ones we don't define we don't define. And if one looks throughout the history of our language and other free languages, it is the latter category that tend to be the non-conformant ones.
pjc50 10y ago
> There is no guarantee that an implementation of Python is bug-free, so there is no guarantee that any Python problem is free of undefined behavior. The implementation being buggy does not mean that the behaviour is undefined in the spec.
- twblalock 10y ago
  Which spec? The one for Python, or the one for C? It's entirely possible that executing a Python program could cause C code in the Python interpreter, or C code called via FFI, to do something that the C spec defines as undefined behavior. That could affect the result of the Python program. If that happened, it would not be reasonable to say that the Python program did not have undefined behavior -- even if nothing in the Python code was undefined according to the Python spec.