You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
[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 functionThe result of the conversion is implementation-defined.
The text was updated successfully, but these errors were encountered:
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
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?
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:
Is this intended to imply that converting the same pointer value to an integer multiple times must result in the same integer? That is:
[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:
The text was updated successfully, but these errors were encountered: