https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117785
--- Comment #32 from Jonathan Wakely <redi at gcc dot gnu.org> --- (In reply to Hana Dusíková from comment #28) > (In reply to Jakub Jelinek from comment #27) > > Jason Merrill asked for that during patch review: > > https://gcc.gnu.org/pipermail/gcc-patches/2025-July/688997.html > > "This will work for any class type with a what() method, which is > > different from vterminate.cc that only calls what() for a type derived > > from std::exception. I think it makes sense to be consistent with that; > > a what() from an unrelated class might mean something different." This is true, but thinking about it further ... > Okay, what I tried (and failed to my limited knowledge of doing it lowlevel > without AST present) is to allow any `constexpr const` overload of `what` > without arguments which returns pointer to any char type or anything which > has `.size()` and `.data()` returning pointer to any char type. ... at compile-time does it matter if the what() function does something else? It can't launch missiles or format hard drives during consteval. The worst it can do is print garbage to the terminal, but a type derived from std::exception could do that too. If the type wasn't intended to be used as an exception, it wouldn't have been thrown by the program! I suppose all the same arguments apply at runtime but executing arbitrary code at runtime does seem more worrying, even though it's true that somebody could do: struct Evil : std::exception { const char* what() const override { system("rm -rf /"); } };
