kern/76520: Add new kernel-side libiconv converter for mounting NTFS under UTF-8

David Yu davidyu at ucsd.edu
Fri Jan 21 09:10:21 PST 2005


The following reply was made to PR kern/76520; it has been noted by GNATS.

From: David Yu <davidyu at ucsd.edu>
To: Andrey Chernov <ache at nagual.pp.ru>
Cc: freebsd-gnats-submit at FreeBSD.ORG
Subject: Re: kern/76520: Add new kernel-side libiconv converter for mounting
 NTFS under UTF-8
Date: Fri, 21 Jan 2005 09:07:51 -0800

 The encodings this converter intended to support are just general 
 encodings, i.e., encodings that can be directly computed from/to unicode 
 without mapping tables. Please don't confuse them with other encodings. 
 The current situation is that we still use translation table even with 
 encodings that can be efficiently (in terms of space) computed.
 
 Besides, those patches from R. Imura for UTF-8 just increased the 
 character size from 2 to 4 bytes. However, a character in UTF-8 can be 
 as long as 6 bytes.
 
 Andrey Chernov wrote:
 > On Fri, Jan 21, 2005 at 01:40:45AM +0000, David Yu wrote:
 > 
 >>>Description:
 >>
 >>The kernel-side libiconv currently used cannot convert unicode characters to UTF-8 which are longer than 2 bytes due to the lack of general encoding
 >>converter. This patch adds a new converter for encoding UCS-2 and UTF-8, but can easily extend to cover all general encodings.
 > 
 > 
 > There is no needs to adds something into kernel or we ends up in tons of 
 > unneded encodings embedded, encoding modules must be made as klds. I 
 > even remember I saw some code in the freebsd-i18n archive.
 > 
 
 


More information about the freebsd-bugs mailing list