linux-kernel - Re: [PATCH] console UTF-8 fixes

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <461E5212.8070807@zytor.com>
Date:	Thu, 12 Apr 2007 08:36:50 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Egmont Koblinger <egmont@...linux.hu>
CC:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Jan Engelhardt <jengelh@...ux01.gwdg.de>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] console UTF-8 fixes

Egmont Koblinger wrote:
> 
> I don't think width information for characters in BMP is going to change
> that often.
> 
> By the way, a note about the size: the larger one of the two tables is
> unused and hence optimised away by the compiler. I just left in the source
> so that it only takes a minor modification for people go get a different
> sane behavior (ie. ignore combining chars). So only the small table, with 11
> pairs of longs (88 bytes) are compiled to the kernel.
> 

Every version has added combining chars.  But anyway, please don't leave 
unused code in the kernel.  I agree doublewidth characters are largely 
range-based and thus not all that likely to change.

>> At least please put them in a separate .c file and include a script to 
>> generate them clean from UnicodeData.txt.
> 
> I'll look at it, but I didn't want to alter the building procedure, modify
> Makefiles... Or do you mean I should only ship the generated .c file plus
> the script, instead of the (1MB) UnicodeData.txt and generating it compile
> time? Sounds reasonable...

Right.  However, see above.

>> Besides, would it not make more sense to have a single table with the 
>> width information, if you insist on having one, instead of multiple ones?
> 
> I've been thinking on it and I'm not sure which one the right way is. The
> reason for choosing this was probably that this way information that is not
> used by the code can be omitted by the compiler.

Then let's leave it out of the source.
-
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/