TranslateWord2 uses phonemes in ph_list2. Apart from the breakable loops, it
may statically require up to 7 phonemes. Then TranslateClause always
uses 2 phonemes. We thus have to keep these margins along the loops to
avoid any overflow.

Fixes #1073 #1095

Now that all usan errors are fixed.

Ref #220

This avoids having to make LoadEnvelope2 pass &env_x[-1], which is very
strongly frowned upon by sanitizers such as usan.

TranslateWord2 uses phonemes in ph_list2. Apart from the breakable loops, it
may statically require up to 7 phonemes. Then TranslateClause always
uses 2 phonemes. We thus have to keep these margins along the loops to
avoid any overflow.

Fixes #1073

Valgrind reports:

==3642987== Conditional jump or move depends on uninitialised value(s)
==3642987==    at 0x491F268: TranslateNumber_1 (numbers.c:1785)
==3642987==    by 0x4923C35: TranslateNumber (numbers.c:2080)
==3642987==    by 0x49556DC: TranslateWord3 (translate.c:644)
==3642987==    by 0x4957FCE: TranslateWord (translate.c:1100)
==3642987==    by 0x4959344: TranslateWord2 (translate.c:1361)
==3642987==    by 0x496116E: TranslateClause (translate.c:2613)
==3642987==    by 0x494FF7A: SpeakNextClause (synthesize.c:1569)
==3642987==    by 0x4939B9D: Synthesize (speech.c:457)
==3642987==    by 0x493AE6A: sync_espeak_Synth (speech.c:570)
==3642987==    by 0x493B286: espeak_ng_Synthesize (speech.c:678)
==3642987==    by 0x4916925: espeak_Synth (espeak_api.c:90)
==3642987==    by 0x10CF5D: main (espeak-ng.c:691)
==3642987==  Uninitialised value was created by a stack allocation
==3642987==    at 0x495BD9F: TranslateClause (translate.c:1941)

Indeed, TranslateNumber_1 looks back up to three bytes before, with
IsDigit09(word[-3])), so we have to increase the heading margin to three
spaces.

valgrind reports

==3632264== Conditional jump or move depends on uninitialised value(s)
==3632264==    at 0x4846688: strcmp (vg_replace_strmem.c:924)
==3632264==    by 0x490EC12: LookupDictList (dictionary.c:2889)
==3632264==    by 0x49554C6: TranslateWord3 (translate.c:588)
==3632264==    by 0x4957FCE: TranslateWord (translate.c:1100)
==3632264==    by 0x4959344: TranslateWord2 (translate.c:1361)
==3632264==    by 0x4961390: TranslateClause (translate.c:2621)
==3632264==    by 0x494FF7A: SpeakNextClause (synthesize.c:1569)
==3632264==    by 0x4939B9D: Synthesize (speech.c:457)
==3632264==    by 0x493AE6A: sync_espeak_Synth (speech.c:570)
==3632264==    by 0x493B286: espeak_ng_Synthesize (speech.c:678)
==3632264==    by 0x4916925: espeak_Synth (espeak_api.c:90)
==3632264==    by 0x10CF5D: main (espeak-ng.c:691)

And indeed tr->phonemes_repeat may not necessarily be initialized.

espeak source code uses signed integer wrapping (e.g. wavephase in
wavegen.c's Wavegen). It happens that this is undefined behavior, so a
compiler would be free optimize away various situations... Fortunately gcc
has an -fwrapv option to make signed integer wrapping defined.

Options would be needed for other compilers.

shifting negative integers has an undefined behavior, so we have to
avoid it entirely. Using * 256 and / 256 provides the expected behavior
while being correctly optimized by the compiler.

this is the maximum espeak-ng's speech rate without using libsonic

event_notify currently introduces an arbitrary 50ms delay between speech
requests. This is usually unnoticed since it's small. But when
cancelling a long series of events, they add up to potentially seconds
of delays, while the user was precisely requesting to just cancel
everything as fast as possible.

This 50ms delay was probably meant to work around some issues elsewhere.
If they are still there, they should be fixed, not worked around.

Signed-off-by: Ulrich Müller <[email protected]>

https://github.com/espeak-ng/espeak-ng/issues/1072

Signed-off-by: Ulrich Müller <[email protected]>

The links persisted when ./configure run with extended dictionaries
disabled.

This reverts commit 433d219eca.