RMQR: update to new draft ISO/IEC JTC1/SC31N000 (Draft 2019-6-24);
allow for righthand vertical timing pattern in populate_grid()
ULTRA: update max size and min cols based on BWIPP 2021-07-14 update
backend_tcl/zint_tcl.dsp: use /MD instead of /MT for tcl lib compat;
change include/lib path to more standard one
manual.txt: highlight that rMQR is still in development
GUI: use cross-platform smaller font func instead of explicit values for notes
bmp/emf/ps.c: allow for foreground colour in ULTRA
bmp/gif/pcx.c: allow for BARCODE_STDOUT (fflush/fclose)
emf.c: hexagon rotation field not used; dont't use float index in font loop; Windows stdout binary mode
png.c: remove unused 8-bit; simplify libpng error handling and fclose outfile on error
ps.c: fix buffer overflow on colour_to_pscolor() CMYK
tif.c: fix BLACKISZERO indexes
CODE39: simplify check digit setting
reedsol.c: rs_uint_init_gf() log/alog tables must be zeroed
ZBarcode_Encode: debug: fix access out-of-bounds on non-NUL-terminated source if length < 10
manual.txt/zint.h: document NUL-terminated strings
tests: cover further cases for output (bmp/emf/etc), eci/gb18030/gb2312/sjis, reedsol, AZTEC, CODE39
Sanitizers require both front and backend support on the target platform.
Detect whether applications can be compiled and linked with sanitizer support
and enable sanitizers that can be both compiled and linked with.
check_c_compiler_flags is insufficient here, because we need library support
on top of just compiler support.
This implicitly disables sanitizer support for most cross-compiling and
embedded targets which use gcc or llvm based toolchains but don't have library
support, while enabling it on MSVC and Intel compilers.
While here, bind the sanitizer dependency to the zint library targets, and
remove the hardcoded no-var-tracking-assignments. variable assignment
tracking is a very powerful tool to find the true source of uninitialized
value based conditional jumps, and, if undesired, it can be disabled by
configuring the ASAN_OPTIONS environment variable.
In `aztec_text_process`, `binary_string`, which aliases to `aztec`'s
`bit_pattern` has it's first element set to NUL. However, when the string
is later written into using `bin_append_posn`, that NUL is overwritten and
further NUL to replace it is not appended.
In general, the garbage collected memory content should never be assumed to
have a specific value unless a value was explicitly assigned, so the content
of `bit_pattern` cannot be safely assumed to be NUL.
If the string is not NUL terminated, functions relying on NUL termination,
such as the printf call at the end of `aztec_text_proccess` itself,
will overrun the array bounds.
Explicitly initialize `bit_pattern`
