[integer] long long warning

[Vladimir Prus-3]

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-2]

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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Dmitry Goncharov-2]

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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Vladimir Prus-3]

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


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Sascha Ochsenknecht-2]

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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[John Maddock]

> 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.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Daniel James]

On Tue, Nov 10, 2009 at 9:48 AM, John Maddock <john@...> 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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[John Maddock]

>> 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.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Beman Dawes]

On Tue, Nov 10, 2009 at 5:41 AM, Daniel James <daniel_james@...> wrote:

> On Tue, Nov 10, 2009 at 9:48 AM, John Maddock <john@...> 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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[John Maddock]

>>> 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.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Daniel James]

2009/11/11 John Maddock <john@...>:
>
> 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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Beman Dawes]

On Wed, Nov 11, 2009 at 2:02 PM, John Maddock <john@...> 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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost