Re: Current CVS Mule 21.2 crashes (on X only?)

mb> I would like to keep the arg of CHARSET_BY_LEADING_BYTE as is, mb> since it is actually logically a bufbyte. No, it's not, in this case; it's an enum LEADING_BYTE_OFFICIAL_1. The point being that there are several ways to hit that assert, and not all of them pass through a buffer. From the comment in the preceding version (which you should not have deleted; you should have disagreed with it), that's exactly the reasoning that led to the arg being an int in the first place. I agree that we _wish_ it were a Bufbyte, but if we were all that confident of that, we wouldn't need the assert. A real buffer byte that gets fed to that assert presumably was acquired via VALIDATE_CHARPTR_BACKWARD and friends, and already passes the assert. IIRC, leading bytes are also used to identify charsets in redisplay internals. It's not so hard to imagine a programming error in which an Emchar gets put somewhere that eventually ends up hitting that assert, is it? SJT> GCC bug, maybe? mb> Maybe. Is it possible inline functions with unsigned char mb> arguments don't have proper conversions from int? As karlheg would say "you tell me and we'll both know". I'm not a member of the bar in C. Note that as I mention above the argument also has to be converted first from enum LBO1 to Bufbyte; this would imply a GCC bug, though, because that conversion should already be a fact when the assert is hit. I'm more suspicious of this type_checking_assert. What is it? Is this a C9x thing? mb> Could you investigate some more? Yes. You've probably seen Yoshiki's message already, but there's himi's report "assertion of CHARSET_BY_LEADING_BYTE fails on gcc-2.95.2 20000220." himi says -O0 wins for him and provides assembler output to show why. I haven't tried it, will do so if you insist. Yoshiki's suggestion of -fno-gcse in that thread does NOT win for me, it pukes on the same assertion with the same C backtrace that Himi and I have both posted (I checked that Himi's is the same). mb> If you load a cyrillic keyboard mapping before starting X, do mb> you have the same problem? Yes, I do (on keysym 1738, which is in the Cyrillic range according to the logic in event-Xt.c). mb> Is it dependent on compiler flags? Any further suggestions for compiler flags to try? Better hurry, XF86 4.0 just showed up in Debian woody, and I probably won't have a reliable workstation to test on for a couple of weeks after "upgrading" to that :-P -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules."