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

[expr.reinterpret.cast] Must pointer to integer conversion be consistent? #623

Open
randomnetcat opened this issue Oct 10, 2024 · 1 comment

Comments

@randomnetcat
Copy link

randomnetcat commented Oct 10, 2024

Full name of submitter: Janet Cobb

Reference (section label): [expr.reinterpret.cast]

Link to reflector thread (if any): N/A

Issue description:

[expr.reinterpret.cast]/4-5 reads:

A pointer can be explicitly converted to any integral type large enough to hold all values of its type. The mapping function is implementation-defined.

A value of integral type or enumeration type can be explicitly converted to a pointer. A pointer converted to an integer of sufficient size (if any such exists on the implementation) and back to the same pointer type will have its original value ([basic.compound]); mappings between pointers and integers are otherwise implementation-defined.

Is this intended to imply that converting the same pointer value to an integer multiple times must result in the same integer? That is:

int* p = /* something */;
assert(reinterpret_cast<std::uintptr_t>(p) == reinterpret_cast<std::uintptr_t>(p)); // OK?

[expr.reinterpret.cast]/4 describes the conversion as having a "mapping function", which would imply that applying the mapping to a single input must yield a single output. However, [expr.reinterpret.cast]/5 describes both directions of the conversion as a "mapping", which does not necessarily carry the same implication.

P2434 would clarify that the mapping from integers to pointers is not necessarily a function, but would not alter the relevant wording for the pointer to integer direction.

Suggested resolution:

If the conversion must be consistent, it is likely that no wording change is necessary, but a clarification (or at least a note) might be useful.

If converting a single pointer can yield different integers:

A pointer can be explicitly converted to any integral type large enough to hold all values of its type. The mapping function The result of the conversion is implementation-defined.

@randomnetcat randomnetcat changed the title [expr.reinterpret.castl] Must pointer to integer conversion be consistent? [expr.reinterpret.cast] Must pointer to integer conversion be consistent? Oct 10, 2024
@frederick-vs-ja
Copy link

frederick-vs-ja commented Oct 11, 2024

Perhaps it will be easier to resolve this after adopting P2434. E.g. it might be able to specify that the mapping between bit values value representations of pointer and integers have one-to-one correspondence.

On most contemporary platforms, perhaps we should say an integer value is converted from or to uintptr_t if it is not, and each value representation of uintptr_t is one-to-one corresponding to that of (any) pointer type.

However, what should be specified when

  • uintptr_t doesn't exist (so the reinterpret_cast can be only from integer to pointer), or
  • uintptr_t exists, but its representable range is "larger" than those of pointers?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants