Confliction between [expr.cast] and "shall not discard cv-qualification"
Nobody has claimed this yet.
- Dominant language
- TeX
- Stars
- 221
- Forks
- 813
- Avg merge
- 16h 4m
- Merged PRs (30d)
- 36
Description
Please see this minimum example
char const* v = 0;
int* identifier = (int*)v;
As per [expr.cast#4], the conversion should undergo that as specified below
The conversions performed by
- [...]
- a reinterpret_cast followed by a const_cast
can be performed using the cast notation of explicit type conversion. The same semantic restrictions and behaviors apply, ...
In other words, the conversion should firstly use reinterpret_cast, after that, const_cast is used to produce the ultimate result.
As per [expr.reinterpret.cast#7]
An object pointer can be explicitly converted to an object pointer of a different type.60 When a prvalue v of object pointer type is converted to the object pointer type “pointer to cv T”, the result is static_cast<cv T*>(static_cast<cv void*>(v)).
The source type is "pointer to const char" while the destination type is "pointer to int", hence the middle result produced by reinterpret_cast is equivalent to static_cast<int*>(static_cast<void*>(v)) since the cv is empty.
As per [expr.static.cast#1] or [conv.ptr#2]
The static_cast operator shall not cast away constness ([expr.const.cast]).
A prvalue of type “pointer to cv T”, where T is an object type, can be converted to a prvalue of type “pointer to cv void”. The pointer value ([basic.compound]) is unchanged by this conversion.
In either rule, the cv-qualification of the source type shall not be discarded from the destination type. In the nested conversion of the above conversion, namely static_cast<void*>(v), the destination type is void* while the source type is char const*, this conversion discards the const qualification, it seems that "The same semantic restrictions and behaviors apply" does not intend to give the privileged that discards cv-qualification to any conversion produced by explicit type conversion.
However, the example is accepted by all major implementations, it's reasonable to be considered well-formed. Despite that, it cannot be well interpreted by the standard.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the cited wording in [expr.cast], [expr.reinterpret.cast], [expr.static.cast], and [conv.ptr], then compare those rules against the minimum C++ example in the issue. Determine whether the interaction is inconsistent and identify the precise standard wording that needs clarification; done means the interpretation is resolved and an accepted wording change is specified.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp
- Domain
- documentation
- Issue type
- Documentation
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 20/100