fmt v8 currently contains a bug that causes compilation to fail if
`FMT_USE_USER_DEFINED_LITERALS` is defined to 0. This is a regression
from earlier versions. A bug has been filed against fmt:
https://github.com/fmtlib/fmt/issues/2384
MKVToolNix defined this to 0 as earlier fmt versions caused warnings
in their code dealing with user-defined literals with
`-Wpedantic`. Luckily those warnings do not occur with v8 anymore.
The fix is to test in `configure` if the fmt version we're compiling
with is v8 or older, and only to define
`FMT_USE_USER_DEFINED_LITERALS` to 0 for earlier versions.
Fixes#3151.
Somewhere in the code seemed to be a conversion from to 32-bit integer
types for storing or converting from/to seconds since epoch. This
means that dates before seconds-since-epoch 0 (1970-01-01 00:00:00
UTC) or after seconds-since-epoch std::max<int32_t>() (2038-01-19
03:14:08 UTC) could not be converted to displayable strings.
Qt's QDateTime is not affected by this issue, not even on
Windows. Therefore the header editor wasn't affected as it solely used
QDateTime for all conversions, not the C & C++ standard library
functions.
This only happened on Windows.
Affected were mkvmerge (values in JSON identification mode, timestamps
in track statistics tags), mkvinfo (outputting any EBML date element),
MKVToolNix GUI's info tool (again outputting any EBML data element).
Fixes#3148.
The specs say that hours must be at least two digits, meaning more
than 99 hours must be supported.
The specs also contain suggested ways for parsers to be a bit more
lenient with certain aspects of the timestamps:
1. Spaces & tabs at the start of the line are OK.
2. Arbitrary number of space & tabs around the arrow are OK.
3. The hours component can also be one digit only.
Fixes & implements #3139.
Newer mingw gcc versions (10.3.0, 11) report that there was a
potential write beyond the end of an internal buffer in a QByteArray
instance. It is entirely unclear to me how that could happen, but it
has to do with the conversion from `constexpr auto … = "C-string"` to
`std::string` instances.
As those URLs don't really need to be available at compile time,
converting them to be returned on demand at runtime seemed fine. The
warning is gone now, but again, I don't fully understand the why &
how.
This is in preparation of fixing #3137. The plan is not to use
libfile's MIME type detection but Qt's. As both mkvmerge and the GUI
need to auto-detect the MIME type, this means that the command line
applications will have to be linked against Qt's core library (but not
the GUI libraries).
This is in preparation of fixing #3137. The plan is not to use
libfile's MIME type detection but Qt's. As both mkvmerge and the GUI
need to auto-detect the MIME type, this means that the command line
applications will have to be linked against Qt's core library (but not
the GUI libraries).
