Can we suppress integer_traits warnings?
If you have a program that simply includes boost/integer_traits.hpp and is compiled with g++ -pedantic you get a bunch of warnings: ./boost/integer_traits.hpp:164:57: warning: use of C99 long long integer constant ./boost/integer_traits.hpp:164:73: warning: use of C99 long long integer constant ./boost/integer_traits.hpp:170:62: warning: use of C99 long long integer constant ./boost/integer_traits.hpp:170:62: warning: use of C99 long long integer constant And no matter where I insert __extension__ I can't seem to get gcc to suppress these:-( Any ideas? BTW I'm asking because this came to me as a - somewhat misplaced - bug report: https://svn.boost.org/trac/boost/ticket/1451. Thanks, John.
John Maddock wrote:
If you have a program that simply includes boost/integer_traits.hpp and is compiled with g++ -pedantic you get a bunch of warnings:
./boost/integer_traits.hpp:164:57: warning: use of C99 long long integer constant ./boost/integer_traits.hpp:164:73: warning: use of C99 long long integer constant ./boost/integer_traits.hpp:170:62: warning: use of C99 long long integer constant ./boost/integer_traits.hpp:170:62: warning: use of C99 long long integer constant
And no matter where I insert __extension__ I can't seem to get gcc to suppress these:-(
Any ideas?
BTW I'm asking because this came to me as a - somewhat misplaced - bug report: https://svn.boost.org/trac/boost/ticket/1451.
Thanks, John.
gcc has a pragma to do just that #pragma GCC diagnostic ignored "-Wlong-long" dgoncharov@localhost /root/testsrc/diag $ cat main.cpp #include <boost/integer_traits.hpp> //#pragma GCC diagnostic ignored "-Wlong-long" int main() { typedef boost::integer_traits<long long> traits; bool const a = traits::is_integer; (void) a; return 0; } dgoncharov@localhost /root/testsrc/diag $ g++ main.cpp -Wall -Wextra -pedantic main.cpp: In function 'int main()': main.cpp:8: warning: ISO C++ 1998 does not support 'long long' dgoncharov@localhost /root/testsrc/diag $ vim main.cpp dgoncharov@localhost /root/testsrc/diag $ cat main.cpp #include <boost/integer_traits.hpp> #pragma GCC diagnostic ignored "-Wlong-long" int main() { typedef boost::integer_traits<long long> traits; bool const a = traits::is_integer; (void) a; return 0; } dgoncharov@localhost /root/testsrc/diag $ g++ main.cpp -Wall -Wextra -pedantic dgoncharov@localhost /root/testsrc/diag $ BR, Dmitry
gcc has a pragma to do just that #pragma GCC diagnostic ignored "-Wlong-long"
That doesn't help us because we can't use that in the integer_traits.hpp header to suppress the warning in one place and then reset it back to it's original state. Also the gcc docs say: "Also, while it is syntactically valid to put these pragmas anywhere in your sources, the only supported location for them is before any data or functions are defined. " So basically only end users can use the pragma (at the start of a source file before any headers are #included) which again doesn't help us library authors :-( Cheers, John.
John Maddock wrote:
gcc has a pragma to do just that #pragma GCC diagnostic ignored "-Wlong-long"
That doesn't help us because we can't use that in the integer_traits.hpp header to suppress the warning in one place and then reset it back to it's original state. Also the gcc docs say:
"Also, while it is syntactically valid to put these pragmas anywhere in your sources, the only supported location for them is before any data or functions are defined. "
So basically only end users can use the pragma (at the start of a source file before any headers are #included) which again doesn't help us library authors :-(
Cheers, John.
It is also possible to suppress this warning by a command line switch -Wno-long-long BR, Dmitry
It is also possible to suppress this warning by a command line switch -Wno-long-long
Sure, but we need to fix the *library header file* so it doesn't emit warnings even when the user has asked for those warnings: we do this already for long long usage within Boost, but I can't find a workaround for constants with LL suffixes. John.
On 26.10.2009, at 13:21, John Maddock wrote:
Sure, but we need to fix the *library header file* so it doesn't emit warnings even when the user has asked for those warnings: we do this already for long long usage within Boost, but I can't find a workaround for constants with LL suffixes.
Maybe #pragma GCC system_header is an option? Regards, Daniel
Sure, but we need to fix the *library header file* so it doesn't emit warnings even when the user has asked for those warnings: we do this already for long long usage within Boost, but I can't find a workaround for constants with LL suffixes.
Maybe #pragma GCC system_header is an option?
Ahah! That certainly seems to work, adding: #if defined(__GNUC__) && ((__GNUC__ > 3) || ((__GNUC__ == 3) && (__GNUC_MINOR__ > 3))) // // The following code emits warnings when built with -pedantic, and there appears // to be no other way of suppressing these warnings as use of __extension__ has no // effect, so declare the rest of this header a system header. // # pragma GCC system_header #endif near the end of the header, suppresses those warnings. Any downsides or objections to this? Thanks, John.
Maybe #pragma GCC system_header is an option?
Ahah! That certainly seems to work, adding:
#if defined(__GNUC__) && ((__GNUC__ > 3) || ((__GNUC__ == 3) && (__GNUC_MINOR__ > 3))) // // The following code emits warnings when built with -pedantic, and there appears // to be no other way of suppressing these warnings as use of __extension__ has no // effect, so declare the rest of this header a system header. // # pragma GCC system_header #endif
near the end of the header, suppresses those warnings.
Any downsides or objections to this?
A downside is that #pragma GCC system_header suppreses all warnings, not just the one you need to suppress. BR, Dmitry
----- Original Message ----- From: "Dmitry Goncharov" <dgoncharov@unison.com> To: <boost@lists.boost.org> Sent: Monday, October 26, 2009 4:24 PM Subject: Re: [boost] Can we suppress integer_traits warnings?
Maybe #pragma GCC system_header is an option?
Ahah! That certainly seems to work, adding:
#if defined(__GNUC__) && ((__GNUC__ > 3) || ((__GNUC__ == 3) && (__GNUC_MINOR__ > 3))) // // The following code emits warnings when built with -pedantic, and there appears // to be no other way of suppressing these warnings as use of __extension__ has no // effect, so declare the rest of this header a system header. // # pragma GCC system_header #endif
near the end of the header, suppresses those warnings.
Any downsides or objections to this?
A downside is that #pragma GCC system_header suppreses all warnings, not just the one you need to suppress.
If you reach to isolate in a separated file the parts concerned by the warning, the #pragma GCC system_header will be less invasive. I understand that this could be confusing just to remove some warnings. Just an idea :) Vicente
A downside is that #pragma GCC system_header suppreses all warnings, not just the one you need to suppress.
If you reach to isolate in a separated file the parts concerned by the warning, the #pragma GCC system_header will be less invasive. I understand that this could be confusing just to remove some warnings.
Nod. However, in this case the only code in the header after the pragma is the problem code causing the warnings, so I'm not sure we gain much? John.
John Maddock wrote:
A downside is that #pragma GCC system_header suppreses all warnings, not just the one you need to suppress.
If you reach to isolate in a separated file the parts concerned by the warning, the #pragma GCC system_header will be less invasive. I understand that this could be confusing just to remove some warnings.
Nod. However, in this case the only code in the header after the pragma is the problem code causing the warnings, so I'm not sure we gain much?
The pragma applies to the entire header, not just to the code following it, IIUC. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
Nod. However, in this case the only code in the header after the pragma is the problem code causing the warnings, so I'm not sure we gain much?
The pragma applies to the entire header, not just to the code following it, IIUC.
Are you sure? The gcc docs say: "There is also a directive, #pragma GCC system_header, which tells GCC to consider the rest of the current include file a system header, no matter where it was found. Code that comes before the `#pragma' in the file will not be affected." John.
John Maddock wrote:
The pragma applies to the entire header, not just to the code following it, IIUC.
Are you sure? The gcc docs say:
"There is also a directive, #pragma GCC system_header, which tells GCC to consider the rest of the current include file a system header, no matter where it was found. Code that comes before the `#pragma' in the file will not be affected."
That looks to be definitive and I can only point to my "IIUC" caveat, because I clearly did not understand correctly! _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
John Maddock wrote:
Sure, but we need to fix the *library header file* so it doesn't emit warnings even when the user has asked for those warnings: we do this already for long long usage within Boost, but I can't find a workaround for constants with LL suffixes.
Have you considered computing the values at compile time instead of using constants? BR, Dmitry
Have you considered computing the values at compile time instead of using constants?
Sigh... that's the last ditch solution I guess, we could certainly do that for the usual case that long long is a 64-bit int, but really we *should* be using limits.h for these constants IMO. Besides, as it's someone else's code/library really, I'd really rather apply a trivial/quick fix if I can! John.
John Maddock wrote:
It is also possible to suppress this warning by a command line switch -Wno-long-long
Sure, but we need to fix the *library header file* so it doesn't emit warnings even when the user has asked for those warnings: we do this already for long long usage within Boost, but I can't find a workaround for constants with LL suffixes.
Hmm, it may even look like violation of the Boost guideline: "Don't declare integral constant expressions whose type is wider than int." http://www.boost.org/development/int_const_guidelines.html Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org
AMDG Mateusz Loskot wrote:
John Maddock wrote:
It is also possible to suppress this warning by a command line switch -Wno-long-long
Sure, but we need to fix the *library header file* so it doesn't emit warnings even when the user has asked for those warnings: we do this already for long long usage within Boost, but I can't find a workaround for constants with LL suffixes.
Hmm, it may even look like violation of the Boost guideline:
"Don't declare integral constant expressions whose type is wider than int."
This is irrelevant since constant in question is LLONG_MAX. There's no way around a large integer constant. In addition, this code in question is in the middle of a bunch of compiler #ifdefs, so portability issues should already be handled. In Christ, Steven Watanabe
Steven Watanabe wrote:
AMDG
Mateusz Loskot wrote:
John Maddock wrote:
It is also possible to suppress this warning by a command line switch -Wno-long-long
Sure, but we need to fix the *library header file* so it doesn't emit warnings even when the user has asked for those warnings: we do this already for long long usage within Boost, but I can't find a workaround for constants with LL suffixes.
Hmm, it may even look like violation of the Boost guideline:
"Don't declare integral constant expressions whose type is wider than int."
This is irrelevant since constant in question is LLONG_MAX. There's no way around a large integer constant. In addition, this code in question is in the middle of a bunch of compiler #ifdefs, so portability issues should already be handled.
Thank you for clarification, makes sense. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org
participants (7)
-
Daniel Frey -
Dmitry Goncharov -
John Maddock -
Mateusz Loskot -
Steven Watanabe -
Stewart, Robert -
vicente.botet