This replaces uses of:
memcpy(dst, src, strlen(src))
with:
strcpy(dst, src)
This fixes issues with reading past the end of the copied buffer
(e.g. when processing word-based replacements for emoji characters)
by ensuring that the destination buffer is null terminated.
Reported by Michael Curran <[email protected]>
Clang static analysis reports an 'Assigned value is garbage or
undefined' for this. If no points were read from the file, the
`n_points` variable is 0 and `env_x[n_points-1]` performs an
out-of-bounds access.
Clang static analysis reports an 'Assigned value is garbage or
undefined' error. This happens if the default_tune data has not
been copied in the kTUNE case.
Extending this further, it does not make sense to save the tune
data if the tune was not found, or if the tune already exists.
This was identified by the clang static analyser. The letter
variable is set in the various match_type switch cases, so
does not need to be initialised in the start of the while loop.
Clang static analysis reports a 'Dereference of null pointer'
error when accessing wtab->flags. This is properly guarded
against when setting the wflags variable, so use that variable
instead.
Clang static analysis reports this as several 'Result of operation
is garbage or undefined' errors, when `ending` has not been set
due to no matching endings.
The definitions for towlower() and towupper() are defined in /usr/include/wctype.h on FreeBSD platforms. I just removed the define and used the ucd_ equivilent where towlower/towupper were found.
/bin/sh ./libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H -I. -fPIC -fvisibility=hidden -pedantic -fno-exceptions -D PATH_ESPEAK_DATA=\"/usr/local/share/espeak-
ng-data\" -DLIBESPEAK_NG_EXPORT -Isrc/include -Isrc/include/compat -I src/ucd-tools/src/include -D_BSD_SOURCE -D_DEFAULT_SOURCE -D_POSIX_C_SOURCE=200112L -Wno-endif-lab
els -g -O2 -std=c99 -MT src/libespeak-ng/src_libespeak_ng_la-readclause.lo -MD -MP -MF src/libespeak-ng/.deps/src_libespeak_ng_la-readclause.Tpo -c -o src/libespeak-n
g/src_libespeak_ng_la-readclause.lo `test -f 'src/libespeak-ng/readclause.c' || echo './'`src/libespeak-ng/readclause.c
libtool: compile: cc -DHAVE_CONFIG_H -I. -fPIC -fvisibility=hidden -pedantic -fno-exceptions -D PATH_ESPEAK_DATA=\"/usr/local/share/espeak-ng-data\" -DLIBESPEAK_NG_EXPO
RT -Isrc/include -Isrc/include/compat -I src/ucd-tools/src/include -D_BSD_SOURCE -D_DEFAULT_SOURCE -D_POSIX_C_SOURCE=200112L -Wno-endif-labels -g -O2 -std=c99 -MT src/li
bespeak-ng/src_libespeak_ng_la-readclause.lo -MD -MP -MF src/libespeak-ng/.deps/src_libespeak_ng_la-readclause.Tpo -c src/libespeak-ng/readclause.c -fPIC -DPIC -o src/l
ibespeak-ng/.libs/src_libespeak_ng_la-readclause.o
In file included from src/libespeak-ng/readclause.c:32:
In file included from src/include/compat/wctype.h:30:
/usr/include/wctype.h:73:8: error: conflicting types for 'ucd_tolower'
wint_t towlower(wint_t);
^
src/include/compat/wchar.h:37:18: note: expanded from macro 'towlower'
^
src/ucd-tools/src/include/ucd/ucd.h:503:13: note: previous declaration is here
codepoint_t ucd_tolower(codepoint_t c);
^
In file included from src/libespeak-ng/readclause.c:32:
In file included from src/include/compat/wctype.h:30:
/usr/include/wctype.h:74:8: error: conflicting types for 'ucd_toupper'
wint_t towupper(wint_t);
^
src/include/compat/wchar.h:38:18: note: expanded from macro 'towupper'
^
src/ucd-tools/src/include/ucd/ucd.h:491:13: note: previous declaration is here
codepoint_t ucd_toupper(codepoint_t c);
^
src/libespeak-ng/readclause.c:366:19: warning: implicit declaration of function 'mkstemp' is invalid in C99 [-Wimplicit-function-declaration]
if ((fd_temp = mkstemp(fname_temp)) >= 0)
^
1 warning and 2 errors generated.
This is related to ebfa320956169e3419234b72fee51bd596867661, but
when reading the hash chain entry length, not writing it.
If char is signed, then before this change the length would be
negative, causing problems loading the dictionary.
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]>