I would have used ": int" explicitly in the enum to make the issue
more clear if C supported it.

The rule in C is that an enum type and its underlying type are
"compatible", meaning that they can be aliased. C++ is stricter in
what types it allows to be aliased, but it does allow some, such as
"unsigned" and "int" being allowed to alias each other.

The optimization opportunities here seem minimal, and it loses
expected behavior that C has.

On Tue, May 10, 2022 at 2:51 PM Jason McKesson via Std-Discussion
<std-discussion_at_[hidden]> wrote:
>
> On Tue, May 10, 2022 at 5:09 PM Myria via Std-Discussion
> <std-discussion_at_[hidden]> wrote:
> >
> > What is the reasoning behind C++'s type aliasing rules prohibiting
> > accessing an enum through a pointer to its underlying type? This
> > differs from C and feels counter-intuitive when C++ does allow
> > accessing an int from an unsigned pointer.
> >
> > enum Kitty { KITTY };
> > enum Kitty Test(enum Kitty* x, int* y)
> > {
> > *x = KITTY;
> > *y = -1;
> > return *x;
> > }
> >
> > This works in C when x and y alias, returning (Kitty) -1, but in C++
> > is undefined behavior.
>
> I don't know what the rule is in C, but in C++, implementations are
> free to make `Kitty` have an underlying type of `short`. Or `char`. So
> this is not required to work in C++ *regardless* of the rules relating
> to underlying types.
>
> A good reason not to allow this is that it would potentially break
> existing optimization opportunities. In the above code, the compiler
> can assume that `*y` has no effect on `*x` and make optimizations
> based on that.
> --
> Std-Discussion mailing list
> Std-Discussion_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion