<xthreads.h>
: Use enum class _Thrd_result
for type safety
#3897
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I was briefly investigating #292 again due to a related user report, where it turned out that that specific problem was fixed by #3721. For the general problem of defending the STL against all unconstrained operator overloads, it's unclear whether we can practically solve it, or whether we should devote significant effort towards doing so (considering that it isn't a regression, and that plenty of UCRT/VCRuntime/PPLTasks headers are also affected). I note this because I don't want to encourage a bunch of follow-up PRs in this area.
However, I noticed that
<xthreads.h>
uses an unnamed, unscoped enumeration for its result codes, which are returned asint
. This came to my attention because it leads toint
s being compared to these enumerators (hence this can be hijacked by unconstrained operator overloads), but I decided to do something about it because it's a bad practice even aside from the operator overloading issue.The most important observation is that all of these types and functions (except
_Throw_C_error()
inthread0.cpp
, discussed below) areextern "C"
, so we can upgrade this unscoped enum to a scoped enum without breaking ABI or affecting the DLL's export surface, as long as we keep the underlying type the same (justint
) and don't change the enumerator values (obvious). In addition to this semi-mechanical transformation, I'm shortening the comment// TRANSITION, ABI: Always returns _Thrd_success
(with occasional case variation) to// TRANSITION, ABI: Always succeeds
in order to avoid wrapping.Finally, because it throws an exception, the preserved-for-bincompat
_Throw_C_error()
inthread0.cpp
is C++ mangled, notextern "C"
. Therefore, it must continue to takeint code
, and muststatic_cast<_Thrd_result>(code)
within.I've verified with
dumpbin /exports
that the export surfaces of the release and debug DLLs are unchanged.