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.
tests/language.test: Use different hashing commands when needed
Outside of Linux platforms, sha1 hashing from the command-line is accomplished
by commands other than sha1sum. OSX uses shasum and FreeBSD uses sha1, so I've
added in detection for the appropriate command before falling back and failing
the test.
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.
FreeBSD requires __BSD_VISIBLE to be set to expose M_PI and mkstemp() in the
system includes. This is normally set when _ANSI_SOURCE, _C99_SOURCE, or
_C11_SOURCE are undefined. I don't want to dig into what the compiler is
setting, so I'm just setting it in the configure script.
/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-labels -g -O2 -std=c99 -MT src/libespeak-ng/src_libespeak_ng_la-wavegen.lo -MD -MP -MF src/libespeak-ng/.deps/src_libespeak_ng_la-wavegen.Tpo -c -o src/libespeak-ng/src_libespeak_ng_la-wavegen.lo `test -f 'src/libespeak-ng/wavegen.c' || echo './'`src/libespeak-ng/wavegen.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_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-labels -g -O2 -std=c99 -MT src/libespeak-ng/src_libespeak_ng_la-wavegen.lo -MD -MP -MF src/libespeak-ng/.deps/src_libespeak_ng_la-wavegen.Tpo -c src/libespeak-ng/wavegen.c -fPIC -DPIC -o src/libespeak-ng/.libs/src_libespeak_ng_la-wavegen.o
src/libespeak-ng/wavegen.c:355:24: error: use of undeclared identifier 'M_PI'
x = 127*(1.0 - cos((M_PI*2)*ix/wavemult_max));
^
src/libespeak-ng/wavegen.c:623:16: error: use of undeclared identifier 'M_PI'
minus_pi_t = -M_PI / samplerate;
^
2 errors generated.
gmake[1]: *** [Makefile:1690: src/libespeak-ng/src_libespeak_ng_la-wavegen.lo] Error 1
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]>