make check failure in 21.5 non-MULE from CVS

Ever since Ben merged his large MULE changes into the main line (4 months ago?), 'make check' has failed for certain non-MULE configurations. This is certainly the case for me, under PPC Linux and configured with: ../xemacs-21.5/configure --prefix=/usr/local/gcc3-world --with-gnome and also for one in a bug report submitted in June: <http://list-archive.xemacs.org/xemacs-beta/200206/msg00007.html> The problem is an assert in tests.c [lines wrapped for clarity]: ./xemacs -vanilla -batch -l /home/malcolmp/devl/xemacs/xemacs-21.5/src/../tests/automated/test-harness.el -f batch-test-emacs /home/malcolmp/devl/xemacs/xemacs-21.5/src/../tests/automated Testing /home/malcolmp/devl/xemacs/xemacs-21.5/tests/automated/base64-tests.el... base64-tests.el: 1232 of 1232 (100%) tests successful. Testing /home/malcolmp/devl/xemacs/xemacs-21.5/tests/automated/byte-compiler-tests.el... byte-compiler-tests.el: 104 of 104 (100%) tests successful. Testing /home/malcolmp/devl/xemacs/xemacs-21.5/tests/automated/c-tests.el... Fatal error: assertion failed, file /home/malcolmp/devl/xemacs/xemacs-21.5/src/tests.c, line 365, !memcmp (BYTE_BUF_BYTE_ADDRESS (current_buffer, charbpos_to_bytebpos (current_buffer, ((current_buffer)->bufpt + 0))), int_foo, sizeof (int_foo) - 1) Running 'make check' on the same system configured with MULE works perfectly. The assert trips as part of a test where the opaque form of the string "\r\n\r\nfoo\r\nbar" is inserted into a buffer using the file coding "undecided" and then compared to the string "\n\nfoo\nbar". It fails because the original string is in the buffer. The two following tests also fail, which relate to putting "\r\n\r\nfoo\r\nbar" and "\r\rfoo\rbar" into strings or stream using the iso-8859-1 file encoding. In reply to the report in June, Ben said in part: Ben> btw i don't think it's a problem with the XEmacs code, but rather a Ben> problem with the tests, since I changed the internal format awhile ago, Ben> around when the bugs started happening. Looking into file-coding.c has not thrown any light into which is right. Does anyone have any suggestions? What should be fixed, the file encoding or the expected test result? Malcolm -- Malcolm Purvis <malcolmpurvis(a)optushome.com.au&gt; The hidden, terrible cost of nuclear warfare is Really Bad Public Art. - Angus McIntyre, alt.peeves, 13/3/02.