New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[basic.fundamental] Unsigned integral type representation is neither unspecified nor implementation-defined CWG2827 #4893
Comments
"Unspecified" means the result can change for every evaluation. It seems the current status where this is simply not mentioned in the specification is fine. If we do anything at all here, we should add a general statement to [basic.types.general] where we introduce padding bits and value/object representation. |
@zygoloid , anything we want to do here? |
To contrast, similar ambiguities are avoided in C17 drafts by the wording:
|
BTW, there are many typedef-names explicitly stated to be unspecified through the standard library. It seems that the current wording permits implementations to define these types differently in different TUs, which leads to almost unavoidable ODR violation. Perhaps CWG and LWG issues are needed to specify something is not required to be documented but required to be consistent. |
Unless I'm mistaken, an extremely pedantic (yet valid) reading of the current wording would imply that any behavior depending on the not-specified details of the integral representation is undefined behavior "by omission." In contrast, if it were unspecified, as in C, this reading would be avoided. |
Editorial meeting decision: Let's try using the sentence from C, and have CWG review that. |
Although signed integral type representation is unambiguously defined in terms of unsigned representation, unsigned integral type representation is never specified any further than the bit-width and padding bits being implementation-defined. It is not clear that the ambiguity in the representation is intended to be unspecified. Notably, all other fundamental types are either defined to have the same representation as one of the integral types, or to have implementation-defined representation.
I believe the intent is that all unspecified behavior be explicitly stated to be unspecified, so this amounts to under-specification.
The text was updated successfully, but these errors were encountered: