In #2798, we discuss the behavior of float-divide-by-zero. On some of our APIs (SPIR-V?), this has an undefined result.
Our API MUST be safe, but it merely SHOULD have consistent behavior as much as we reasonably can.
There are times when we want to say "we don't know what you'll end up with, but you'll get some value". In some systems, you can "freeze" a value, such that even though it might have been an undefined value, you can ensure that some single (arbitrary?) value is chosen.
We've talked before about greater and lesser forms of "undefined" values and behavior, but I think we need to standardize or terms.
From https://en.wikipedia.org/wiki/Unspecified_behavior:
In the C and C++ languages, such non-portable constructs are generally grouped into three categories: Implementation-defined, unspecified, and undefined behavior.
C and C++ distinguish implementation-defined behavior from unspecified behavior. For implementation-defined behavior, the implementation must choose a particular behavior and document it. An example in C/C++ is the size of integer data types. The choice of behavior must be consistent with the documented behavior within a given execution of the program.
"Unspecified value" seems like a valuable term for us, but I kind of want a different name for it so that we can abbreviate these. We're in the business of specifying also, so it can feel weird to specify that it's unspecified. I think we would get the right feeling for "nonspecified" though, which has a more active "deliberately unspecified" feel to it.
I propose this terminology:
- Branching based on an Undefined Value is Undefined Behavior.
- Branching based on a Nonspecified Value is not Undefined Behavior.
In #2798, we discuss the behavior of float-divide-by-zero. On some of our APIs (SPIR-V?), this has an undefined result.
Our API MUST be safe, but it merely SHOULD have consistent behavior as much as we reasonably can.
There are times when we want to say "we don't know what you'll end up with, but you'll get some value". In some systems, you can "freeze" a value, such that even though it might have been an undefined value, you can ensure that some single (arbitrary?) value is chosen.
We've talked before about greater and lesser forms of "undefined" values and behavior, but I think we need to standardize or terms.
From https://en.wikipedia.org/wiki/Unspecified_behavior:
"Unspecified value" seems like a valuable term for us, but I kind of want a different name for it so that we can abbreviate these. We're in the business of specifying also, so it can feel weird to specify that it's unspecified. I think we would get the right feeling for "nonspecified" though, which has a more active "deliberately unspecified" feel to it.
I propose this terminology: