Date: Fri, 23 Feb 2024 23:41:08 +0200
On Fri, 23 Feb 2024 at 23:31, 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.
>
> apparently the background is
> https://github.com/llvm/llvm-project/issues/38717#issuecomment-981004156
> --- apparently the standard only mentions promotions in this context
> for regular enums, not scoped enums.
Ha, yet another literal implementation of the spec, which clang is
traditionally very good
and stringent at, without much.. ..consideration on whether the spec
makes sense. :)
> it seems like there were two possibilities here:
>
> 1. scoped enums were intentionally excluded. (but this was not
> explicitly stated, nor was there any rationale given, so this seems
> unlikely?)
>
> 2. scoped enums were accidentally excluded, because the relevant
> section(s) were missed when updating the specification to include
> scoped enums. (this seems more likely?)
Well.. the problem is that scoped enums fall into the same bucket as other enums
do. The general expectation is that enums get promoted. Mr. Smith says
as much in his response to the clang bug report. Scoped enums don't promote,
because they by design don't implicitly convert to an underlying integral type.
> hopefully we can get clang to at least be quiet about the cases that
> don't need promotion, but i'd very much prefer to avoid a lot of
> unnecessary code churn -- that makes the code less readable for no
> obvious benefit -- is this was indeed an oversight in the spec that we
> can get fixed there to remove the threat of UB.
I'm not sure what's left for WG21 to fix. Richard and Aaron seem to agree this
is an implementation bug in clang.
> it's not the standard's fault, but it's particularly unfortunate that
> this warning is part of -Wformat, which means our current options are
> "disable -Wformat -- including all the definitely-a-bug-right-now
> cases" or "static_cast<int>() in all your debug printf()s" :-(
You mean "all your debug printf()s that print scoped enums", and as an
alternative..
..or, you can surround just the offending call sites with pragmas that
disable the warning.
Note that I'm not claiming that's a pretty solution, but it's an
alternative solution.
<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.
>
> apparently the background is
> https://github.com/llvm/llvm-project/issues/38717#issuecomment-981004156
> --- apparently the standard only mentions promotions in this context
> for regular enums, not scoped enums.
Ha, yet another literal implementation of the spec, which clang is
traditionally very good
and stringent at, without much.. ..consideration on whether the spec
makes sense. :)
> it seems like there were two possibilities here:
>
> 1. scoped enums were intentionally excluded. (but this was not
> explicitly stated, nor was there any rationale given, so this seems
> unlikely?)
>
> 2. scoped enums were accidentally excluded, because the relevant
> section(s) were missed when updating the specification to include
> scoped enums. (this seems more likely?)
Well.. the problem is that scoped enums fall into the same bucket as other enums
do. The general expectation is that enums get promoted. Mr. Smith says
as much in his response to the clang bug report. Scoped enums don't promote,
because they by design don't implicitly convert to an underlying integral type.
> hopefully we can get clang to at least be quiet about the cases that
> don't need promotion, but i'd very much prefer to avoid a lot of
> unnecessary code churn -- that makes the code less readable for no
> obvious benefit -- is this was indeed an oversight in the spec that we
> can get fixed there to remove the threat of UB.
I'm not sure what's left for WG21 to fix. Richard and Aaron seem to agree this
is an implementation bug in clang.
> it's not the standard's fault, but it's particularly unfortunate that
> this warning is part of -Wformat, which means our current options are
> "disable -Wformat -- including all the definitely-a-bug-right-now
> cases" or "static_cast<int>() in all your debug printf()s" :-(
You mean "all your debug printf()s that print scoped enums", and as an
alternative..
..or, you can surround just the offending call sites with pragmas that
disable the warning.
Note that I'm not claiming that's a pretty solution, but it's an
alternative solution.
Received on 2024-02-23 21:41:22