https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90590
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |diagnostic
Status|UNCONFIRMED |NEW
Last reconfirmed| |2019-05-23
Component|libstdc++ |c++
Ever confirmed|0 |1
Severity|normal |enhancement
--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
In theory we could do this to avoid the warning:
--- a/libstdc++-v3/include/bits/ios_base.h
+++ b/libstdc++-v3/include/bits/ios_base.h
@@ -189,13 +189,17 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
operator^=(_Ios_Iostate& __a, _Ios_Iostate __b)
{ return __a = __a ^ __b; }
+ enum _Ios_Seekdir_range
+ {
+ _S_ios_seekdir_beg_ = 0,
+ _S_ios_seekdir_end = 1L << 16
+ };
- enum _Ios_Seekdir
+ enum _Ios_Seekdir : __underlying_type(_Ios_Seekdir_range)
{
_S_beg = 0,
_S_cur = _GLIBCXX_STDIO_SEEK_CUR,
- _S_end = _GLIBCXX_STDIO_SEEK_END,
- _S_ios_seekdir_end = 1L << 16
+ _S_end = _GLIBCXX_STDIO_SEEK_END
};
But giving the enum a fixed underlying type changes its semantics, as now any
value of the underlying type is a valid value of the enumeration type.
As I said in the Clang bug, I think a better approach would be to suppress the
warning for enumerators that are defined in system headers and that use
reserved names.
So I'm changing this to a compiler enhancement request, to suppress this
warning for cases like this.
