`<cassert>`: assert's `_wassert` is shadowable

[Veeloxfire]

trafficstars

Describe the bug

Was checking out cppreference and saw it describing non-compliance in the msvc implementation of assert due to _wassert not taking __func__ and I realised that _wassert is not a reserved identifier and thus can be shadowed

I don't know if this is the job of this repo? I couldn't find the assert macro with a cursory overview, and have previously flagged this issue via the microsoft developer community: https://developercommunity.microsoft.com/t/assert:-_wassert-can-be-shadowed/10741373 (where I was originally told it wasn't an issue but oh well)

Thought I would also flag it here just in case that was the more correct place. Even if its not at least there will be a closed issue to refer to.

Command-line test case

https://godbolt.org/z/j9hWKaa7E

#include <cassert>
#include <iostream>

int main() {
    constexpr auto _wassert = [](const auto&...){};

    assert(1 + 1 != 2);
    std::cout << "Uh oh";
}

is able to reach the print due to the _wassert hyjacking the reporting

Expected behavior

I would expect that it doesn't do this since its technically non-compliant. Im not sure about abi, but I would have thought it fairly trivial to make a __wassert function which just forwards it arguments to _wassert

The example provided is more just my fun example of what this can do in the worst case, I think it more likely that this is an issue when porting code between compilers, either causing a compile error or unexpected behaviour

If someone really wanted to abuse this it being a reserved identifier or not wouldn't stop them though

STL version

Every stl version ever? (or none if its not actually the STL's job)

[frederick-vs-ja]

This is out of the scope of MSVC STL, see #196.

I think the proper resolution would be using ::_wassert in assert. For C, an extension (file scope resolution operator ::, not C++ namespace) is required, but I think such extension is desired.

[StephanTLavavej]

This should be reported to the VS Developer Community as it needs to be fixed in the UCRT. (I'd do it myself, but external customer reports are actually treated with higher priority.)

Note that no C extensions are needed and I strongly recommend against asking for one. The definition of assert can use double colons when __cplusplus is defined, and no double colons otherwise. (That is, if you ask for a C compiler extension, you are asking for your bug report to never be fixed, ever.)

Also note that #4171 exists and will need to be implemented for the C++26 cycle. We may as well feed two cats with one can of tuna.