Skip to content
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

Open
daviddetweiler opened this issue Sep 12, 2021 · 7 comments · May be fixed by #5087
Assignees
Labels
cwg Issue must be reviewed by CWG. not-editorial Issue is not deemed editorial; the editorial issue is kept open for tracking.

Comments

@daviddetweiler
Copy link

daviddetweiler commented Sep 12, 2021

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.

@jensmaurer
Copy link
Member

"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.

@jensmaurer jensmaurer added the decision-required A decision of the editorial group (or the Project Editor) is required. label Sep 12, 2021
@jensmaurer
Copy link
Member

@zygoloid , anything we want to do here?

@daviddetweiler
Copy link
Author

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.

@frederick-vs-ja
Copy link
Contributor

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.

@daviddetweiler
Copy link
Author

daviddetweiler commented Sep 13, 2021

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.

@tkoeppe
Copy link
Contributor

tkoeppe commented Sep 24, 2021

Editorial meeting decision: Let's try using the sentence from C, and have CWG review that.

@tkoeppe tkoeppe removed the decision-required A decision of the editorial group (or the Project Editor) is required. label Sep 24, 2021
@jensmaurer jensmaurer self-assigned this Nov 4, 2021
@jensmaurer
Copy link
Member

CWG2827

@jensmaurer jensmaurer 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 Nov 22, 2023
@jensmaurer jensmaurer 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 Nov 22, 2023
@jensmaurer jensmaurer added cwg Issue must be reviewed by CWG. not-editorial Issue is not deemed editorial; the editorial issue is kept open for tracking. labels Nov 22, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cwg Issue must be reviewed by CWG. not-editorial Issue is not deemed editorial; the editorial issue is kept open for tracking.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants