[Debian-med-packaging] Bug#812378: Bug#812378: snap-aligner: FTBFS: no match for max(unsigned long, _int64)

[Aaron M. Ucko]

Michael Crusoe <michael.crusoe at 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/?amu@monk.mit.edu