Thanks for the analysis. It looks like a version of Read4Bytes (https://github.com/espeak-ng/espeak-ng/blob/master/src/libespeak-ng/readclause.c#L280) for a const char * is needed to fix this -- renaming Read4Bytes to fread_uint32 and create a read_uint32 function. The code would then need to be audited to avoid direct casting to unsigned int *.

Ok, after fixing the condition in FindReplacementChars, it seems I can get back a working generation/transcription with emscripten. I'd still need some expertise to tell me if I'm missing some potential similar alignment problems.

After implementing a temp fix :

while (p[0] != 0 && p[1] != 0 && p[2] != 0 && p[3] != 0) {
				p++;
			}

the parsing of the rules looks ok now, but the translation is still messed up. Found at least one suspicious place (within commit 55c6403) :

https://github.com/espeak-ng/espeak-ng/blob/48719ad642f8a27d352983ab5964463a8c1e033e/src/libespeak-ng/translate.c#L1793-L1799