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`
test_file_unreadable cannot be implemented easily, as files are always
readable by their owner on windows. While `_chmod` is available in the POSIX
compatibility function set, it cannot be used to take away read permissions,
either.
While here, move functional code out of any assert statements. It shall be
executed even when the assertions are disabled
The `CALCIUM` "name" is a macro which expands to a string constant.
Referencing the macro twice will cause it to be expanded twice, resulting
in two string instances which have identical content. By default, gcc will
deduplicate these two strings into the same memory region as gcc detects
the duplicated constant, even when optimization turned off (see
-fmerge-constants and -fmerge-all-constants GCC options).
The C Language specification does not require duplicated constants to be
deduplicated, and, in fact, the GCC manual page also explicitly states
this optimization is not performed for all targets.
Visual C++, in debug mode, does not deduplicate constants. This results
in `count += strchr(CALCIUM,x) - CALCIUM` yielding to negative values as
the substracted CALCIUM's expansion resides on a greater memory address
then the memory allocated for the expansion passed to `strchr`. The
value of `count` is used to compute the checksum, which then is not only
faulty, but also used as an array index without previously checking
whether or not the index is within the array bounds (modulo of a negative
integer is negative, which means out of bounds). This will cause very
difficult to predict behavior, in most cases, however, it will cause a
segmentation fault.
Manually allocate a memory range to contain the string, and use
this range instead of expanding the macro multiple times.
PLESSEY: add options NCR weighted mod-10, hide check digit(s) in HRT
test suite: now runnable under MSVC 2019, 2017, 2015, MinGW/MSYS
win32/README: update with MSVC 2019 and CMake instructions
The testcommon library, which is outside of this link unit, is
referencing the INTERNAL functions, so despite the name they
need to be exported. The export code is copy&pasted from the
ZINT_EXTERN definition which can't be reused over preprocessor
limitations.
We might just use ZINT_EXTERN instead though
The SHARED attribute is forced via the add_library, so the default
value of cmake is ignored. Also, this option should obviously not
be set for the `zint-static` library
