On Fri, 23 Feb 2024 at 21:55, Jonathan Wakely <cxx@kayari.org> wrote:
>
> On Fri, 23 Feb 2024 at 21:44, Jonathan Wakely <cxx@kayari.org> wrote:
> >
> > On Fri, 23 Feb 2024 at 21:32, enh via Std-Proposals
> > <std-proposals@lists.isocpp.org> 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@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals