lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 12 Apr 2007 16:38:54 +0200 (CEST)
From:	Roman Zippel <zippel@...ux-m68k.org>
To:	Egmont Koblinger <egmont@...linux.hu>
cc:	"H. Peter Anvin" <hpa@...or.com>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Jan Engelhardt <jengelh@...ux01.gwdg.de>,
	Pavel Machek <pavel@....cz>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] console UTF-8 fixes

Hi,

On Thu, 12 Apr 2007, Egmont Koblinger wrote:

> I tried to create such a script using ideas for regexps from glibc's
> charmaps/UTF-8, but it seemed to be quite hopeless to create a small table.
> It seems that Markus probably performed some reasonal manual optimisations
> that cannot really be scripted. For example, within a huge CJK area there
> are plenty of codepoints that are not (yet?) assigned. However, if they'll
> be assigned in the future, most likely they'll be double-wide characters
> too.

Considering this possible volatility I'm not certain we really need this 
in the kernel.
The other point is that I have problems imagining, that this should be 
enough to edit random text files with a random editor without problems. 
Especially cursor positioning becomes a whole lot more complex and the 
editor has to do exactly the same parsing as the kernel, i.e. changes to 
this table are not easily possible anymore or later you may need to add 
the possibility to read the table.
OTOH if the editor has to all this parsing anyway, the whole thing could 
be pushed to userspace and the Linux terminal could be marked as handling 
all characters equally (a good hint would be if the terminal doesn't even 
support wide characters). The terminfo database exists for a good reason 
and a good editor has to support a wide range of terminals anyway, so I 
don't really see the problem as to mark variable width characters as not 
supported and keep the kernel implementation sane and simple.

bye, Roman
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ