lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lmi] '-Wsign-promo' seems not to flag anything important


From: Greg Chicares
Subject: [lmi] '-Wsign-promo' seems not to flag anything important
Date: Thu, 21 Mar 2019 16:44:25 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1

We'll soon upgrade gcc, so I figured I'd try some warning options
that we haven't enabled yet. With gcc-7.3 at least (I'll try these
things with gcc-8.2 later, but for now lmi production uses 7.3),
'-Wsign-promo' gives 414 lines of "error:" output, all of which are
like this pair:

/opt/lmi/src/lmi/dbnames.cpp:53:44: error: passing 'e_database_key' chooses 
'int' over 'long unsigned int' [-Werror=sign-promo]
/opt/lmi/src/lmi/dbnames.cpp:53:44: error:   in call to 
'std::basic_ostream<_CharT, _Traits>& std::basic_ostream<_CharT, 
_Traits>::operator<<(int) [with _CharT = char; _Traits = 
std::char_traits<char>]' [-Werror=sign-promo]

I.e., in each flagged case, I pass an enumerative type and am warned
that it's treated as (signed) int...which is exactly how I'd expect
it to be treated. IOW, even if the enumeration's underlying type is
unsigned, to me that's just an artificial detail, as I think of 'int'
as the One True non-floating arithmetic type. (I wouldn't have been
shocked if gcc presupposed some other One True Type, but...see below.)

Maybe someday I'll specify an 'enum-base' underlying type explicitly.
But if I specify 'int', e.g.:

  enum oenum_modal_prem_type : int
      {oe_monthly_deduction
      ,oe_modal_nonmec
      ,oe_modal_table
      };

I get the same number of warnings. And if I specify 'unsigned int',
I still get:

/opt/lmi/src/lmi/ihs_basicval.cpp: In member function 'double 
BasicValues::GetModalSpecAmt(double, oenum_modal_prem_type) const':
/opt/lmi/src/lmi/ihs_basicval.cpp:1404:49: error: passing 
'oenum_modal_prem_type' chooses 'unsigned int' over 'int' [-Werror=sign-promo]
             << "Unknown modal premium type " << premium_type << '.'
                                                 ^~~~~~~~~~~~
/opt/lmi/src/lmi/ihs_basicval.cpp:1404:49: error:   in call to 
'std::basic_ostream<_CharT, _Traits>::__ostream_type& 
std::basic_ostream<_CharT, _Traits>::operator<<(unsigned int) [with _CharT = 
char; _Traits = std::char_traits<char>; std::basic_ostream<_CharT, 
_Traits>::__ostream_type = std::basic_ostream<char>]' [-Werror=sign-promo]
/opt/lmi/src/lmi/ihs_basicval.cpp:1404:49: error: passing 
'oenum_modal_prem_type' chooses 'unsigned int' over 'long unsigned int' 
[-Werror=sign-promo]
/opt/lmi/src/lmi/ihs_basicval.cpp:1404:49: error:   in call to 
'std::basic_ostream<_CharT, _Traits>::__ostream_type& 
std::basic_ostream<_CharT, _Traits>::operator<<(unsigned int) [with _CharT = 
char; _Traits = std::char_traits<char>; std::basic_ostream<_CharT, 
_Traits>::__ostream_type = std::basic_ostream<char>]' [-Werror=sign-promo]
/opt/lmi/src/lmi/ihs_basicval.cpp:1404:49: error: passing 
'oenum_modal_prem_type' chooses 'unsigned int' over 'long int' 
[-Werror=sign-promo]
/opt/lmi/src/lmi/ihs_basicval.cpp:1404:49: error:   in call to 
'std::basic_ostream<_CharT, _Traits>::__ostream_type& 
std::basic_ostream<_CharT, _Traits>::operator<<(unsigned int) [with _CharT = 
char; _Traits = std::char_traits<char>; std::basic_ostream<_CharT, 
_Traits>::__ostream_type = std::basic_ostream<char>]' [-Werror=sign-promo]

...so I guess I was wrong to think that there's some "universal"
'enum-base' type that will suppress this diagnostic. Even if I use
  enum oenum_modal_prem_type : unsigned long int
I still get
  passing 'oenum_modal_prem_type' chooses 'unsigned int' over 'long unsigned 
int'
which seems surprising.

I'm certainly not going to make changes like this:
-    << "Unknown modal premium type " << premium_type << '.'
+    << "Unknown modal premium type " << static_cast<int>(premium_type) << '.'

AFAICS, it's best to leave this warning disabled, and maybe turn it on
temporarily from time to time to see whether it finds anything important.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]