Bug 165798 - Can't input wide-characters with a UTF-8 locale
Can't input wide-characters with a UTF-8 locale
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: newt (Show other bugs)
All Linux
high Severity medium
: ---
: ---
Assigned To: Petr Rockai
Jay Turner
Depends On:
Blocks: 168429
  Show dependency treegraph
Reported: 2005-08-12 08:44 EDT by Bastien Nocera
Modified: 2015-01-07 19:10 EST (History)
7 users (show)

See Also:
Fixed In Version: RHBA-2006-0154
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-03-07 13:27:44 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Screenshot-Terminal.png (25.67 KB, image/png)
2005-08-12 08:44 EDT, Bastien Nocera
no flags Details
newt-entry-double-free.patch (427 bytes, patch)
2005-11-14 06:45 EST, Bastien Nocera
no flags Details | Diff

  None (edit)
Description Bastien Nocera 2005-08-12 08:44:34 EDT

Can't input Japanese text in entries with LANG=ja_JP.UTF-8, but works fine with

Testing (working):
1) Install the newt sources, and compile them
2) Install the gtk-hiragana-input from http://sourceforge.net/cvs/?group_id=52573
3) Launch "LANG=ja_JP.eucJP gnome-terminal --disable-factory -e ./test"
4) Select the "Hiragana Transliterated" input method
5) Try to type in some text

Testing (not working):
Same thing, but 3) should be "LANG=ja_JP.UTF-8 gnome-terminal --disable-factory
-e ./test"

At 3), the terminal should be in Japanese.

The problem comes from entry.c, in entryHandleKey():
       if ( (key >= 0x20 && key <= 0x7e) || (key >= 0xa0 && key <= 0xff) ) {

Making this test an "if (1)" will show the same problem as bug #68728 (see
attached screenshot).
Comment 1 Bastien Nocera 2005-08-12 08:44:34 EDT
Created attachment 117670 [details]
Comment 11 Petr Rockai 2005-11-07 10:01:53 EST
If you have access, could you try what behaviour exhibits the current devel  
(rawhide) version of newt in the above scenario? I suspect this should be  
fixed there, maybe apart from the if(...) part, where we still disallow a  
range of bytes. Commenting this out should however give correct result, unless  
the width computation is still incorrect (it got fixed for utf-8 in that  
version though, and it works with eg czech/utf8 (it didn't really work 
Comment 19 Bastien Nocera 2005-11-14 06:44:28 EST
The test program (included in the sources) crashes with a double-free, with the
0.51.6-6.unofficial.rhel4 package:
#0  0x080606b1 in kill ()
#1  0x0806042c in raise ()
#2  0x080607c0 in abort ()
#3  0x0806cb57 in __libc_message ()
#4  0x08071c91 in _int_free ()
#5  0x08071f6f in free ()
#6  0x0804bec6 in entryDraw (co=0x9a00f50) at entry.c:213
#7  0x0804a97d in newtDrawForm (co=0x9a002c8) at form.c:608
#8  0x0804b18f in newtFormRun (co=0x9a002c8, es=0xbfec2c58) at form.c:911
#9  0x08048936 in main () at test.c:127

You're trying to free the output of alloca(), allocated line 212.
The package seems to work in my limited testing once you've removed that
unneeded free.
Comment 20 Bastien Nocera 2005-11-14 06:45:12 EST
Created attachment 121019 [details]
Comment 34 Red Hat Bugzilla 2006-03-07 13:27:44 EST
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


Note You need to log in before you can comment on or make changes to this bug.