Michael Crusoe <michael.cru...@gmail.com> writes: > Thank you Aaron for your reports.
Thanks for looking into them! > x32 is out of my league; and I suspect outside of upstream's interest > though I have still reported it there for completeness. As I suspected, the i386 build wound up failing in the same fashion. The kfreebsd-i386 build hit a different portability issue, which I'll report shortly. > I made the suggested change but it wasn't sufficient: That makes sense in retrospect, since the original error message did say _int64. It looks like the standard conversion rules, as summarized at http://en.cppreference.com/w/cpp/language/operator_arithmetic, result in different types for bufferSpace / blocks.size() on 32- and 64-bit platforms: this is a size_t / _int64 division, which hits "[I]f the unsigned operand's conversion rank is greater or equal to the conversion rank of the signed operand, the signed operand is converted to the unsigned operand's type." in 64-bit builds but "[I]f the signed operand's type can represent all values of the unsigned operand, the unsigned operand is converted to the signed operand's type." in 32-bit builds. (Never mind that the wider type is in the divisor position!) How about explicitly working in size_t, per getDataReader's signature? static const size_t min_size = 1UL << 17; size_t unadjusted_size = bufferSpace / blocks.size(); i->reader = readerSupplier->getDataReader(1, MAX_READ_LENGTH * 8, 0.0, min(min_size << 6, max(min_size, unadjusted_size))); // 128kB to 8MB buffer space per block -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
