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
The size and alignment of nullptr_t is the same as for a pointer to character type. An object representation of the value nullptr is the same as the object representation of a null pointer value of type void*. An lvalue conversion of an object of type nullptr_t with such an object representation has the value nullptr; if the object representation is different, the behavior is undefined.303)
In C++ it's only required that sizeof(std::nullptr_t) == sizeof(void*). Do we want to specify that alignof(std::nullptr_t) == alignof(void*)? (The superficial wording difference from C doesn't matter due to [basic.compound] p7.)
The UB specified in that paragraph isn't present in C++. In C++, conversions from nullptr_t effectively touch no bit, so the value representation of a nullptr_t object, which is currently unspecified in C++, doesn't matter in most uses. However, the decision on value representation of nullptr_t can lead to different results via bit_cast, and there're implementation divergence (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117727).
Perhaps it's better to specifiy that the value representation (and the valid set of value bits) of nullptr_t is implementation-defined.
[...] sizeof(std::nullptr_t) shall be equal to sizeof(void*)and alignof(std::nullptr_t) shall be equal to alignof(void*). The value representation of std::nullptr_t and the non-empty set of value representations of std::nullptr_t that correspond to values are implementation-defined. [Note ?: An implementation can decide that the value representation of std::nullptr_t contains no bits. — end note]
The text was updated successfully, but these errors were encountered:
I agree about the alignment question, I think we should specify this to be the same as void*, too.
Since C++ opted to never read the bits of the value representation of std::nullptr_t for the lvalue-to-rvalue conversion, I don't think we need to talk about its value representation, and there is no need to require an implementation to document its choice ("implementation-defined"). The results from bit_cast are highly implementation-dependent anyway, so I'm not seeing a problem with the implementation divergence.
jensmaurer
changed the title
[basic.fundamental] Alignment and value representation of nullptr_t
CWG2966 [basic.fundamental] Alignment and value representation of nullptr_tDec 6, 2024
Full name of submitter (unless configured in github; will be published with the issue): Jiang An
Reference (section label): [basic.fundamental]
Link to reflector thread (if any):
Issue description:
nullptr_t
has several properties in C23 that is either not specified or different in C++.WG14 N3220 7.21.2 p3 reads:
In C++ it's only required that
sizeof(std::nullptr_t) == sizeof(void*)
. Do we want to specify thatalignof(std::nullptr_t) == alignof(void*)
? (The superficial wording difference from C doesn't matter due to [basic.compound] p7.)The UB specified in that paragraph isn't present in C++. In C++, conversions from
nullptr_t
effectively touch no bit, so the value representation of anullptr_t
object, which is currently unspecified in C++, doesn't matter in most uses. However, the decision on value representation ofnullptr_t
can lead to different results viabit_cast
, and there're implementation divergence (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117727).Perhaps it's better to specifiy that the value representation (and the valid set of value bits) of
nullptr_t
is implementation-defined.Suggested resolution:
Modify [basic.fundamental] p16 as indicated:
The text was updated successfully, but these errors were encountered: