In Boost ICL, when I call cardinality() or size() functions on an interval set, the return type is size_t, independent of the type of interval. On 32-bit machines this is a 32-bit unsigned integer. If my intervals, however, are of type int64_t, the cardinality can easily overflow the 32-bit integer. Am I missing something obvious here or is this a serious flaw of this library?
EDIT: example added
The following code compiles and runs without error on 64-bit but not on 32-bit machines, where it throws the assertion.
#include <boost/icl/interval_set.hpp>
int main()
{
boost::icl::interval_set<int64_t> is;
is.add(boost::icl::interval<int64_t>::closed(1, 4294967297LL));
assert(boost::icl::cardinality(is) == 4294967297LL);
}
EDIT: I'm using boost::icl version 1.49.0 on Ubuntu 13.10
EDIT:
This is not particularly a 32/64-bit problem, as the following code wouldn't work on 64-bit either
#include <boost/icl/interval_set.hpp>
int main()
{
boost::icl::interval_set<double> is;
is.add(boost::icl::interval<double>::closed(1, 1.5));
assert(boost::icl::cardinality(is) == 0.5);
}
Reproduced with Boost 1_54 on Ubuntu 14.04.1 LTS
This indeed seems to be a bug. The specialization to fix is
In
icl/type_traits/size_type_of.hpp. Somehow the ICL devs appear not to be testing with -m32 these days.I've had success replacing it by
The trait is sadly not very SFINAE friendly, hence the hack to use the first
booltemplate argument for SFINAE. Improvements could be:boosttype traits onlycommon_type<...>for integral typesI've tested this to DoTheRightThing(TM) for
interval_set<double>as well asinterval_set<uint64_t>on g++ -m32 and -m64.I'd report this on the mailing list.