C++ Logo


Advanced search

Re: [std-proposals] scoped enums and varargs

From: Jonathan Wakely <cxx_at_[hidden]>
Date: Fri, 23 Feb 2024 21:55:10 +0000
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,, 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.

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.

Received on 2024-02-23 21:56:27