[libcxx-commits] [libcxx] [libc++] Fix UB in <expected> related to "has value" flag (#68552) (PR #68733)

[Jonathan Wakely via libcxx-commits]

Jan =?utf-8?q?Kokemüller?= <jan.kokemueller at gmail.com>,
Jan =?utf-8?q?Kokemüller?= <jan.kokemueller at gmail.com>,
Jan =?utf-8?q?Kokemüller?= <jan.kokemueller at gmail.com>,
Jan =?utf-8?q?Kokemüller?= <jan.kokemueller at gmail.com>
Message-ID:
In-Reply-To: <llvm/llvm-project/pull/68733/libcxx at github.com>


jwakely wrote:

> To summarize the discussion, I'd like to confirm that the intent of the standard when specifying exposition-only members without `[[no_unique_address]]` is that the implementation doesn't use `[[no_unique_address]]` (which is not a transparent optimization based on what we learned in this thread).

I do not agree that the specification is intended to forbid the use of the attribute. I think that is an over-strict interpretation of the use of exposition-only members. Is the suggestion also that `(void*)&exp == (void*)&exp.value()` must be false, because the standard shows a `bool` member at offset zero, so the `val` member must be at a non-zero offset? I don't think we want to limit implementations to only using _exactly_ the layout shown. The exposition-only members are not required to exist at all, except as needed to implement the public API. I think the specifics of class layout should be non-portable implementation details (except where we say something is a structural type, where it obviously matters).

I think this require an LWG issue, but my preferred direction would be to add blanket wording saying that you cannot assume that any subobjects are not potentially overlapping. The library should be free to use EBO and `no_unique_address` and reorder members, or use tagged pointers etc.

Destroying a member subobject and recreating another object in its place is not a reasonable case of "observable behaviour" IMHO. Users should not be ending the lifetime of private members/subobjects of std::lib types.

> Have you folks run into this issue with your implementation of e.g. `expected`?

No, I didn't use `[[no_unique_address]]` but now I wonder if I should have ...


https://github.com/llvm/llvm-project/pull/68733