Messages in this thread | | | Date | Thu, 12 Apr 2007 08:36:50 -0700 | From | "H. Peter Anvin" <> | 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |