Hi, if, in SVN trunk as of revision 57535, I go to libs/program_options/test and run: bjam warnings=all cxxflags=-Wextra I get a pile of warnings like this: ../../../boost/integer.hpp:145:24: warning: use of C99 long long integer constant These are actually only warnings that are now printed. Does anybody know what to do with them? Thanks, Volodya
I think "long long" is from the C99 standard and the GNU g++ doesn't use this mode by default (?). For me, the warnings disappear if I use add: cxxflags=-std=c++0x Cheers, Sascha Vladimir Prus schrieb:
Hi,
if, in SVN trunk as of revision 57535, I go to libs/program_options/test and run:
bjam warnings=all cxxflags=-Wextra
I get a pile of warnings like this:
../../../boost/integer.hpp:145:24: warning: use of C99 long long integer constant
These are actually only warnings that are now printed. Does anybody know what to do with them?
Thanks, Volodya _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Sascha Ochsenknecht wrote:
I think "long long" is from the C99 standard and the GNU g++ doesn't use this mode by default (?).
For me, the warnings disappear if I use add: cxxflags=-std=c++0x
But on the other hand, it was reported that this mode has quite a number of failures relative to standard mode. And it's not the default anyway. So, I suppose somebody has to patch integer.hpp anyway. - Volodya
Vladimir Prus schrieb:
Sascha Ochsenknecht wrote:
I think "long long" is from the C99 standard and the GNU g++ doesn't use this mode by default (?).
For me, the warnings disappear if I use add: cxxflags=-std=c++0x
But on the other hand, it was reported that this mode has quite a number of failures relative to standard mode. And it's not the default anyway. So, I suppose somebody has to patch integer.hpp anyway.
I agree. The option I added wasn't supposed to be the solution. Just a hint. Cheers, Sascha
Vladimir Prus wrote:
Hi,
if, in SVN trunk as of revision 57535, I go to libs/program_options/test and run:
bjam warnings=all cxxflags=-Wextra
I get a pile of warnings like this:
../../../boost/integer.hpp:145:24: warning: use of C99 long long integer constant
These are actually only warnings that are now printed. Does anybody know what to do with them?
There was a discussion about these warnings recently. One possible solution is to place constants like the following in one of the boost headers. __extension__ unsigned long long const ullong_max = ~static_cast<unsigned long long>(0); __extension__ long long const llong_max = ullong_max >> static_cast<long long>(1); __extension__ long long const llong_min = -llong_max - static_cast<long long>(1); BR, Dmitry
if, in SVN trunk as of revision 57535, I go to libs/program_options/test and run:
bjam warnings=all cxxflags=-Wextra
I get a pile of warnings like this:
../../../boost/integer.hpp:145:24: warning: use of C99 long long integer constant
These are actually only warnings that are now printed. Does anybody know what to do with them?
Not yet, but it hits my stuff as well, so sometime I want to see it fixed. BTW I believe there are quite a few changes to Boost.Integer in Trunk that have never been merged to release as well, which adds extra complications :-( Looking at the code in question, it appears the warning is from the preprocessor phase as the line in question reads: #if BOOST_HAS_XINT && (BOOST_UXINT_MAX > ULONG_MAX) So we can't just declare constants-as-variables in one place to fix this as we need values usable in preprocessor directives. Looks like we'll need another #pragma GCC system_header, and as suggested elsewhere I'll try and add a way to turn off those pragmas in Boost.Config. HTH, John. PS don't let warnings in dependencies stop you from declaring the library "clean" on https://svn.boost.org/trac/boost/wiki/WarningFixes, it's understood that dependencies may cause warnings, but they'll get fixed at some point if we all work through the list.
On Tue, Nov 10, 2009 at 9:48 AM, John Maddock <john@johnmaddock.co.uk> wrote:
Not yet, but it hits my stuff as well, so sometime I want to see it fixed. BTW I believe there are quite a few changes to Boost.Integer in Trunk that have never been merged to release as well, which adds extra complications :-(
They mainly look like new developments, and the test results aren't great so IMO we should probably just move them onto a branch and copy the files from the release branch. They can be merged back later if someone wants to deal with them. Daniel
Not yet, but it hits my stuff as well, so sometime I want to see it fixed. BTW I believe there are quite a few changes to Boost.Integer in Trunk that have never been merged to release as well, which adds extra complications :-(
They mainly look like new developments, and the test results aren't great so IMO we should probably just move them onto a branch and copy the files from the release branch. They can be merged back later if someone wants to deal with them.
I had a quick look, and it appears that: * The test programs take too long to build (someone needs to split them up). * There seems to be a problem with print_out_template in the integer_test.cpp program that is causing many of the failures (only gcc it seems will resolve the overload as intended). If someone thinks they can fix these that would be really cool :-) John.
On Tue, Nov 10, 2009 at 5:41 AM, Daniel James <daniel_james@fmail.co.uk> wrote:
On Tue, Nov 10, 2009 at 9:48 AM, John Maddock <john@johnmaddock.co.uk> wrote:
Not yet, but it hits my stuff as well, so sometime I want to see it fixed. BTW I believe there are quite a few changes to Boost.Integer in Trunk that have never been merged to release as well, which adds extra complications :-(
They mainly look like new developments, and the test results aren't great so IMO we should probably just move them onto a branch and copy the files from the release branch. They can be merged back later if someone wants to deal with them.
I tried some time ago to get Daryle Walker to this straighten out. I'm inclined to agree with Daniel that we should just move the current trunk for this lib to a branch, use the release branch as a starting point, and work from there. --Beman
Not yet, but it hits my stuff as well, so sometime I want to see it fixed. BTW I believe there are quite a few changes to Boost.Integer in Trunk that have never been merged to release as well, which adds extra complications :-(
They mainly look like new developments, and the test results aren't great so IMO we should probably just move them onto a branch and copy the files from the release branch. They can be merged back later if someone wants to deal with them.
I tried some time ago to get Daryle Walker to this straighten out.
I'm inclined to agree with Daniel that we should just move the current trunk for this lib to a branch, use the release branch as a starting point, and work from there.
OK, what was Trunk integer is now in the sandbox under "integer", and Trunk has been reverted back to release branch state. Note that I may have reverted some legitimate "good" fixes in doing this :-( John.
2009/11/11 John Maddock <john@johnmaddock.co.uk>:
OK, what was Trunk integer is now in the sandbox under "integer", and Trunk has been reverted back to release branch state.
Note that I may have reverted some legitimate "good" fixes in doing this :-(
They should be in the branch's history if someone wants to deal with them. I'll look to see if the closed tickets need to be reopened later. Daniel
On Wed, Nov 11, 2009 at 2:02 PM, John Maddock <john@johnmaddock.co.uk> wrote:
OK, what was Trunk integer is now in the sandbox under "integer", and Trunk has been reverted back to release branch state.
Good!
Note that I may have reverted some legitimate "good" fixes in doing this :-(
Sure, but at least we are now at a point where we can start to apply any "good" fixes that we can identify. Thanks, --Beman
participants (6)
-
Beman Dawes -
Daniel James -
Dmitry Goncharov -
John Maddock -
Sascha Ochsenknecht -
Vladimir Prus