mirror of https://github.com/mpv-player/mpv
41e96d8b6b
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. |
||
|---|---|---|
| .. | ||
| m_config.h | ||
| m_config_core.c | ||
| m_config_core.h | ||
| m_config_frontend.c | ||
| m_config_frontend.h | ||
| m_option.c | ||
| m_option.h | ||
| m_property.c | ||
| m_property.h | ||
| options.c | ||
| options.h | ||
| parse_commandline.c | ||
| parse_commandline.h | ||
| parse_configfile.c | ||
| parse_configfile.h | ||
| path.c | ||
| path.h | ||