This is an unofficial snapshot of the ISO/IEC JTC1 SC22 WG21 Core Issues List revision 116a. See http://www.open-std.org/jtc1/sc22/wg21/ for the official list.

2024-12-19

853. Support for relaxed pointer safety

[Voted into WP at March, 2010 meeting.]

According to _N4885_.20.10.5 [util.dynamic.safety] paragraph 16, when std::get_pointer_safety() returns std::pointer_safety::relaxed,

pointers that are not safely derived will be treated the same as pointers that are safely derived for the duration of the program.

However, _N4885_6.7.5.5.4 [basic.stc.dynamic.safety] paragraph 4 says unconditionally that

If a pointer value that is not a safely-derived pointer value is dereferenced or deallocated, and the referenced complete object is of dynamic storage duration and has not previously been declared reachable (_N4885_.20.10.5 [util.dynamic.safety]), the behavior is undefined.

This is a contradiction: the library clause attempts to constrain undefined behavior, which by definition is unconstrained.

Proposed resolution (July, 2009):

Change _N4885_6.7.5.5.4 [basic.stc.dynamic.safety] paragraph 4 as follows to define the terms “strict pointer safety” and “relaxed pointer safety,” which could then be used by the library clauses to achieve the desired effect:

An implementation may have relaxed pointer safety, in which case the validity of a pointer value does not depend on whether it is a safely-derived pointer value or not. Alternatively, an implementation may have strict pointer safety, in which case if If a pointer value that is not a safely-derived pointer value is dereferenced or deallocated, and the referenced complete object is of dynamic storage duration and has not previously been declared reachable (_N4885_.20.10.5 [util.dynamic.safety]), the behavior is undefined. [Note: this is true even if the unsafely-derived pointer value might compare equal to some safely-derived pointer value. —end note] It is implementation-defined whether an implementation has relaxed or strict pointer safety.