Repository navigation
[basic.fundamental] Unsigned integral type representation is neither unspecified nor implementation-defined CWG2827 #4893
Description
Activity
"Unspecified" means the result can change for every evaluation.
"Implementation-defined" means the implementation must document its choice.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.
- addeddecision-requiredA decision of the editorial group (or the Project Editor) is required.A decision of the editorial group (or the Project Editor) is required.
on Sep 12, 2021 @zygoloid , anything we want to do here?
To contrast, similar ambiguities are avoided in C17 drafts by the wording:
The representations of all types are unspecified except as stated in this subclause.
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.
Reacted by David DetweilerUnless 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.
- removeddecision-requiredA decision of the editorial group (or the Project Editor) is required.A decision of the editorial group (or the Project Editor) is required.
on Sep 24, 2021 - changed the title
[-][basic.fundamental] Unsigned integral type representation is neither unspecified nor implementation-defined[/-][+]CWG2827 [basic.fundamental] Unsigned integral type representation is neither unspecified nor implementation-defined[/+]on Nov 22, 2023 - changed the title
[-]CWG2827 [basic.fundamental] Unsigned integral type representation is neither unspecified nor implementation-defined[/-][+][basic.fundamental] Unsigned integral type representation is neither unspecified nor implementation-defined CWG2827[/+]on Nov 22, 2023 - addedcwgIssue must be reviewed by CWG.Issue must be reviewed by CWG.not-editorialIssue is not deemed editorial; the editorial issue is kept open for tracking.Issue is not deemed editorial; the editorial issue is kept open for tracking.
on Nov 22, 2023
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.