From xemacs-m  Fri Mar 14 02:43:57 1997
Received: from pentagana.sonic.jp (root@tokyo-04-152.gol.com [202.243.51.152])
	by xemacs.org (8.8.5/8.8.5) with ESMTP id CAA08444
	for <xemacs-beta@xemacs.org>; Fri, 14 Mar 1997 02:43:55 -0600 (CST)
Received: (from jhod@localhost) by pentagana.sonic.jp (8.7.1+2.6Wbeta4/3.4W3) id PAA00601; Fri, 14 Mar 1997 15:25:25 +0900
Date: Fri, 14 Mar 1997 15:25:25 +0900
Message-Id: <199703140625.PAA00601@pentagana.sonic.jp>
From: P E Jareth Hein <jhod@po.iijnet.or.jp>
To: Valdis.Kletnieks@vt.edu
Cc: Steven L Baur <steve@miranova.com>, xemacs-beta@xemacs.org
Subject: Re: locale 
In-Reply-To: <199703131640.LAA20796@black-ice.cc.vt.edu>
References: <199703130349.VAA04503@mharnois.workgroup.net>
	<m2wwrc1lh3.fsf@altair.xemacs.org>
	<199703131640.LAA20796@black-ice.cc.vt.edu>
Mime-Version: 1.0 (generated by tm-edit 7.105)
Content-Type: text/plain; charset=US-ASCII

>>>>> "Valdis" == Valdis Kletnieks <Valdis.Kletnieks@vt.edu> writes:

Valdis> On 12 Mar 1997 20:09:44 PST, you said:
>> Michael Harnois writes:
>> 
>> > Oooh. It says it when I start xemacs, too.
>> 
>> It's coming from XEmacs XIM code.  Putting LANG=C in your
>> environment might make the message go away.  It would probably be
>> better to find out why the call to setlocale(LC_ALL, "") is
>> failing.

Valdis> FWIW, I was just trying to play with the XIM support the other
Valdis> day, and got into a major horrorshow on AIX 4.2.  To Wit:

Valdis> When running with the locale set to C, or en_US, or Lv_LV
Valdis> (which are ASCII, ISO8859-1, and ISO8859-4 based,
Valdis> respectiviely), all worked pretty much as expected (although I
Valdis> admit I did *NOT* do any testing on composing/inputting any
Valdis> characters in the top half of 8859-4).

Valdis> Running with LV_LV however, flamed it out spectacularly.
Valdis> LV_LV is apparently a UTF-8 based locale.  Now, I *know* that
Valdis> I'd be massively surprised if it *worked*, but I must admit
Valdis> being equally surprised at just how *hard* it took the SIGSEGV
Valdis> (like.. I expected gdb to *catch* it ;)

Chances are good that it crashed and burned with a trashed stack frame
due to the malloc dainbramage in Xlib's imDef* files. I'll send a
patch to this list tonight.

--Jareth

