It is dangerous insofar as it pollutes an immense number of source
files. For example, utf8cpp's stuff uses relative namespace
names (e.g. `utf8::some_type`). If `using namespace libebml` is in
effect, then this clashes with `libebml::utf8` which is a typedef for
`unsigned char`, causing compiler errors.
libintl.h defines a preprocessor define for `snprintf` with the
content of `libintl_snprintf` if the C library isn't GNU's
glibc. Therefore `std::snprintf` actually becomes
`std::libintl_snprintf` which doesn't exist. This affects e.g. mingw
and macOS.
Due to the addition on new mandatory elements the calculation of default
sizes for void elements is different. Therefore most test cases have had
their checksums updated.
The old revision has a serious memory usage issue. For example, on
Windows a 650 KB JSON file results in memory usage of roughly 2 GB of
allocated RAM that won't be freed anymore.
The updated version doesn't have this problem anymore.
Fixes#1631.
- convert gcc to use -include
- add clang support for -include
- new target namespace: pch (invoke rake -T or pch:overview for details)
- move pch logic into rake.d/pch.rb
- convert a few troublesome source files from ISO-8859-1 -> UTF-8
- add persistent config: config.pch.json
- add TTY support for running commands with filters (keeps pretty
color diagnostics even when filtering compiler stdout/stderr)
- for fun try:
drake "pch[pretty]"
drake -j4
drake pch:status
Otherwise 64bit values > maximum int64_t are output as signed ones, and
mkvmerge doesn't need to output signed integer values at the moment.
I've also opened an issue for that:
https://github.com/nlohmann/json/issues/151
The dwFlags field in idx1 chunks can have other bits set, too. However,
the code in AVI_read_frame() needs it to be equal to 0x10 (which is
AVIIF_KEYFRAME from the aviriff.h header).
