Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[specialized.algorithms.general] The note seems incorrect #6143

Closed
frederick-vs-ja opened this issue Feb 21, 2023 · 1 comment · Fixed by #6157
Closed

[specialized.algorithms.general] The note seems incorrect #6143

frederick-vs-ja opened this issue Feb 21, 2023 · 1 comment · Fixed by #6157

Comments

@frederick-vs-ja
Copy link
Contributor

[specialized.algorithms.general]/3 says that:

[Note 1: When invoked on ranges of potentially-overlapping subobjects ([intro.object]), the algorithms specified in [specialized.algorithms] result in undefined behavior. — end note]

However, this is a non-normative note, and maybe sometimes incorrect.

In this example

#include <memory>

int main()
{
    struct B {};
    struct D : B {};
    D d;
    std::construct_at(static_cast<B*>(&d));
    // or use an uninitialized_* algorithm to create a new B object
    // ... other operations
    std::construct_at(&d);
}

the newly created B object doesn't transparently replace the original base class subobject, and hence the lifetime of d is ended by the operation. But the program may still have well-defined behavior, as long as the pointer or reference to d or its base class subobject is carefully used.

@CaseyCarter
Copy link
Contributor

CaseyCarter commented Feb 21, 2023

I was trying to make a point that complete-object initialization "on top of" a subobject can zero tail padding bits where some other object lives, but this isn't an issue for the C++ abstract machine: storage reuse ends the lifetime of "other object" anyway. The note isn't clear enough to communicate anything but FUD in any case. We could change it to "can result in undefined behavior" to make it correct, but without any clarification I think it would still be useless. ("[Note: Here there be dragons.—end note]")

I no longer think it's worth our effort to try to warn people that these footguns are even more footgunnish than the average C++ footgun. I think we should just strike the note.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants