On Fri, Feb 23, 2024 at 5:05 PM Jonathan Wakely via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On Fri, 23 Feb 2024 at 21:55, Jonathan Wakely <cxx_at_[hidden]> wrote:
> >
> > On Fri, 23 Feb 2024 at 21:44, Jonathan Wakely <cxx_at_[hidden]> wrote:
> > >
> > > On Fri, 23 Feb 2024 at 21:32, enh via Std-Proposals
> > > <std-proposals_at_[hidden]> wrote:
> > > >
> > > > (https://isocpp.org/std/submit-issue led me to believe there isn't a
> > > > public bug database, and i should send a mail here.)
> > > >
> > > > clang recently started warning about using scoped enums as arguments
> > > > to varargs functions without a cast. this caused a lot of warning
> spam
> > > > in Android, and a lot of confusion as to why there's even a warning
> > > > here.
> > >
> > > Is this about varargs functions in general, or printf?
> > >
> > > I think it's intentional they don't promote when passed via varargs.
> > > Why should you get implicit conversions from scoped enumeration types
> > > when they don't implicitly convert under any other circumstances?
> >
> > Also, the wording in [expr.call] very clearly talks about scoped
> > enumeration types, so I find it very hard to believe that anybody
> > forgot to say what happens for them _when adding the wording about
> > what happens for them_:
> >
> > "Passing a potentially-evaluated argument of a **scoped enumeration
> > type** (9.7.1) or of a class type (Clause 11) having an eligible
> > non-trivial copy constructor (11.4.4, 11.4.5.3), an eligible
> > non-trivial move constructor, or a non-trivial destructor (11.4.7),
> > with no corresponding parameter, is conditionally-supported with
> > implementation-defined semantics.
>
> The current wording is due to
> https://cplusplus.github.io/CWG/issues/2347.html
>
> There was a suggestion to do what you want (implicitly promote if the
> underlying type would be promoted) but that was not the final
> direction that was approved.
>

I think CWG made the right decision not to invent a promotion here given
that there was no evidence of design intent to have a promotion here... but
it doesn't mean someone can't bring a paper proposing to change the design.

Suppose we changed the standard to say that passing a scoped enum to an
ellipsis is equivalent to passing the underlying type after any applicable
promotions, and that a scoped enum type is considered compatible with the
promoted underlying type for the purposes of `va_arg`. Would that break any
existing implementations? I think it would just remove existing UB in code
like the OP's.


>
>
>
> >
> > So the compiler decides whether to reject it at compile time, or to
> > accept and and decides how to pass that argument (maybe it treats it
> > the same as the underlying type of the enum) so that it can be
> > retrieved as its original type. But if it allows passing it, printf
> > still won't know how to extract it again. So it really is undefined,
> > in the same way as printf("%f", 1) is: the type being passed does not
> > match the printf specifier being used.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>

-- 
*Brian Bi*