Skip to content

[libcxx] Initialize vcruntime __std_exception_data in the exception copy ctor #144329

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.

Sign up for GitHub

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

Merged
merged 1 commit into from
Aug 5, 2025
Merged

[libcxx] Initialize vcruntime __std_exception_data in the exception copy ctor #144329

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion libcxx/include/__exception/exception.h
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -48,7 +48,7 @@ class exception { // base of all library exceptions
__data_._DoFree = true;
}

exception(exception const&) _NOEXCEPT {}
exception(exception const&) _NOEXCEPT : __data_() {}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a reason we don't do a proper copy? What happens if two TUs are linked where we provide our own implementation while the other is provided by vcruntime?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a reason we don't do a proper copy?

To properly do a copy, the real vcruntime here calls the __std_exception_copy helper function (to do a proper deep copy of the contained data structure). This dummy implementation here, used when compiling in the no-vcruntime setup, is intentionally a no-op - which is usually fine. However here the too-much-no-op case makes the compiler do incorrect conclusions when compiling with optimizations enabled.

What happens if two TUs are linked where we provide our own implementation while the other is provided by vcruntime?

Not sure it this dummy implementation is being mangled differently to avoid collisions, or if that's a latent bug for anybody doing mixed bugs. Clearly a potential issue - but mostly orthogonal to this patch.


exception& operator=(exception const&) _NOEXCEPT { return *this; }

Expand Down
Loading