From 41e96d8b6bdef6afffe8fc89b2f09cae31e9a8da Mon Sep 17 00:00:00 2001 From: wm4 Date: Wed, 18 Mar 2020 20:51:38 +0100 Subject: options: fix OPT_BYTE_SIZE upper limits As an unfortunate disaster, min/max values use the type double, which causes tons of issues with int64_t types. Anyway, OPT_BYTE_SIZE is often used as maximum for size_t quantities, which can have a size different from (u)int64_t. OPT_BYTE_SIZE still uses in64_t, because in theory, you could use it for file sizes. (demux.c would for example be capable of caching more than 2GB on 32 bit platforms if a file cache is used. Though for some reason the accounting code still uses size_t, so that use case is broken. But still insist that it _could_ be used this way.) There were various inconsistent attempts to set m_option.max to a value such that the size_t/int64_t upper limit is not exceeded. Due to the double max field, this didn't really work correctly. Try to fix this with the M_MAX_MEM_BYTES constant. It's a good approximation, because on 32 bit it should allow 2GB (untested, also would probably exhaust address space in practice but whatever), and something "high enough" in 64 bit. For some reason, clang 11 still warns. But I think this might be a clang bug, or I'm crazy. The result is correct anyway. --- options/m_option.h | 3 +++ 1 file changed, 3 insertions(+) (limited to 'options/m_option.h') diff --git a/options/m_option.h b/options/m_option.h index fc48b42bd2..84336ae3ce 100644 --- a/options/m_option.h +++ b/options/m_option.h @@ -627,6 +627,9 @@ extern const char m_option_path_separator; #define OPT_BYTE_SIZE(field) \ OPT_TYPED_FIELD(m_option_type_byte_size, int64_t, field) +// (Approximation of x<=SIZE_MAX/2 for m_option.max, which is double.) +#define M_MAX_MEM_BYTES MPMIN((1ULL << 62), (size_t)-1 / 2) + #define OPT_GEOMETRY(field) \ OPT_TYPED_FIELD(m_option_type_geometry, struct m_geometry, field) -- cgit v1.2.3