https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81598
Nathaniel Shead <nshead at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |nshead at gcc dot gnu.org
--- Comment #10 from Nathaniel Shead <nshead at gcc dot gnu.org> ---
(In reply to Julien Blanc from comment #9)
> I recently ran into this while trying to use -fsanitize=enum for the
> codebase. The situation is worse for C++ enum class : since you can only
> assign them with static_cast, no load check can be done (clang also fails to
> detect such cases).
>
> Here’s a sample code that should trigger but does not :
>
> #include <iostream>
>
> enum class Foo
> {
> foo1 = 0,
> foo2 = 1
> };
> std::ostream& operator<<(std::ostream& o, Foo foo)
> {
> switch(foo)
> {
> case Foo::foo1:
> return o << "foo1";
> case Foo::foo2:
> return o << "foo2";
> }
> return o << "unknown";
> }
> int main()
> {
> Foo foo = static_cast<Foo>(3);
> std::cout << foo << std::endl;
> return 0;
> }
>
>
> $ g++ -fsanitize=enum -fsanitize=undefined -fno-sanitize-recover enum.cpp
> $ ./a.out
> unknown
> $
>
> Note that clang++ is no better :
>
> $ clang++-7 -fsanitize=enum -fsanitize=undefined -fno-sanitize-recover=all
> enum.cpp
> $ ./a.out
> unknown
> $
>
> But i’d expect both checkers to detect such misuse. While it could be valid
> code, there’s a high chance that its a bug. Ideally an attribute could be
> used if it is expected behaviour.
FWIW I don't think this particular case is UB; an 'enum class' has fixed
underlying type (int by default), and so the valid values are any that fit in
the range of 'int'.
In particular this is relevant because 'std::byte' is defined like `enum class
byte : unsigned char {};`, and providing such values should not cause a
warning/error.
