Strictly speaking, we are not supposed to use memcmp to compare strings
since we are not supposed to read beyond \0, which memcmp is supposed to
potentially do. Sanitizers would warn about it, and using strncmp happens to
provide the proper semantic while being not really slower, so better
just use them.
compiledict.c: change 'temp' to "${dict}temp" temporary file
This way we can compile multiple dictionaries at a time without
stepping on 'temp' file from different compilation steps:
$ make -j8 -B
...
make[1]: *** [Makefile:3082: espeak-ng-data/an_dict] Segmentation fault (core dumped)
make[1]: *** Deleting file 'espeak-ng-data/an_dict'
make[1]: *** [Makefile:3082: espeak-ng-data/az_dict] Segmentation fault (core dumped)
make[1]: *** Deleting file 'espeak-ng-data/az_dict'
code cleanup: Check all local includes with include-what-you-use
Going through files in src/libespeak-ng/, include-what-you-use removed a
few unnecessary includes and included explanations on why a certain
header should be included. This makes tracking globals and dependencies easier.
Running the codebase through IWYU should be repeated after each major
code restIncludes to standard c library weren't checked to avoid
breaking builds with other platforms.
See https://github.com/include-what-you-use/include-what-you-use
The replacement tests for bs, hr, and sr are no longer marked as
broken as they work using the old code. The mk tests keep the
broken annotation, as they don't work in the old code either.
This reverts commit 801a8d197c.
This reverts commit 64d5701e5e.
This reverts commit 3b51ebf617.
This reverts commit 1fd235d2c0.
This reverts commit 9f0667de86.
The length is stored as the first byte in the output from
compile_line. As the data pointer is char, if char is signed then
length could be negative resulting in undefined behaviour. This
commit fixes the issue by reading and writing that byte as a
uint8_t.
This bug was caused by 2a00ca79f6.
Previously, the entries could only be a maximum of 128 bytes, and
would not be negative on platforms with signed chars. That
commit was made to support long emoji entries, especially for
non-Latin languages where the utf-8 representations could be
longer than 128 bytes.
This change also adds some documentation to make it clearer what
is going on. NOTE: The code should really be using actual struct
objects instead of writing to opaque char buffers.
Reported by Reef Turner <[email protected]>