<exception>: exception's constructor from const char* is non-conforming

[alexismailov2]

STL/stl/inc/exception

Line 91 in 0c34074

explicit __CLR_OR_THIS_CALL exception(const char* _Message = "unknown", int = 1) noexcept : _Ptr(_Message) {}

[miscco]

Could you please edit the issue so that the content is in the description and the title is short and precise?

[alexismailov2]

exception class should not have constructor with string it brokes compatibility with gcc stl and clang stl... Also standart describe that exception should be just base class without any strings or pointers to characters internally...

[CaseyCarter]

exception class should not have constructor with string it brokes compatibility with gcc stl and clang stl...

Can you give an example of a program that would be well-formed in the absence of this constructor that is rendered ill-formed by its presence?

Also standart describe that exception should be just base class without any strings or pointers to characters internally...

The standard does not specify private class members. It does sometimes depict private class members for purposes of exposition, but a standard library class isn't required to have private members depicted in the standard and may have other private members not depicted in the standard.

[timsong-cpp]

Direct-initialization from a type with user-defined conversions to both exception and const char*? Both GCC and clang would reject such a case if there's a constructor from const char*; MSVC doesn't but that seems nonconforming (the ICSes are indistinguishable).

[Berrysoft]

I think we all misread the code. This exception class is in namespace stdext, and the real std::exception, the one is conforming, is in vcruntime_exception.h, which is not in this repo.

[CaseyCarter]

I think we all misread the code. This exception class is in namespace stdext, and the real std::exception, the one is conforming, is in vcruntime_exception.h, which is not in this repo.

std::exception is defined in <vcruntime_exception.h> when _HAS_EXCEPTIONS == 1, it has similarly problematic constructor overload(s). stdext::exception is pulled into std via using-declaration when _HAS_EXCEPTIONS == 0. Ideally we'll fix both classes.

Unfortunately we haven't managed to open-source vcruntime yet, so at least that part will have to be done by a MSFT employee. The fact that it's weirdness in vcruntime means we'll also need to determine if the compiler depends on that weirdness or not, and possibly spread the fixing even further.

[Berrysoft]

Ok, I didn't notice _HAS_EXCPTIONS, but it is also an extension, which is not conforming, right?

Actually I don't think it is problematic. The standard library should allow all conforming code, but needn't prevent nonconforming code. There are many extensions in this STL, and all could be stated as nonconforming - some methods is marked noexcept but the standard not (too many), some methods has other default parameters but the standard not (for example, std::basic_fstream::open(const char*, std::ios_base::openmode, int)), some constructors is not in the standard (for example, std::basic_fstream::basic_fstream(FILE*)), and even some overloads is provided when wchar_t is defined as a native type instead of a typedef of unsigned short. If you write portable code, you simply do not rely on these extensions.

I agree that if you write some code like

template <typename T, typename = void>
struct has_pointer_to_const_char_constructor : std::false_type {}

template <typename T>
struct has_pointer_to_const_char_constructor<T, std::enable_if_t<decltype(T{std::declval<const char*>()})>> : std::true_type {}

static_assert(!has_pointer_to_const_char_constructor<std::exception>::value);

you will get unexcepted result, but I cannot understand why you would do that.

[timsong-cpp]

The whole point of Casey's original question (and my comment in response) is that this extension in fact breaks some (arguably contrived) conforming code.

[Berrysoft]

Seems weird, but OK.

But there are many other classes which has constructors not conforming. Do you mean that they should all be modified?

[StephanTLavavej]

The Standard explicitly permits noexcept strengthening, and it also permits constructors and other non-virtual member functions to vary with default arguments. However, it requires implementations to otherwise behave as if no additional overloads are declared. exception(const char*) and basic_fstream(FILE*) violate that rule, but I'd say that the former is significantly less desirable than the latter.

The problem with removing this, aside from the std vs. stdext issue, is that there is a ridiculous amount of user code that has grown to be dependent on this bug/extension. I think we'll need to Microsoft-deprecate it for a number of years before we can contemplate outright removal (and I am a huge proponent of removing non-Standard extensions).