linux-kernel - Re: vfat filesystem: Why utf8=1 when iocharset=”utf8” was already there?

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>] [day] [month] [year] [list]

Date:	Mon, 5 Sep 2011 09:04:47 +0900
From:	NamJae Jeon <linkinjeon@...il.com>
To:	OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>
Cc:	Amit Sahrawat <amit.sahrawat83@...il.com>,
	linux-kernel@...r.kernel.org
Subject: Re: vfat filesystem: Why utf8=1 when iocharset=”utf8” was already there?

2011/9/3 OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>:
> NamJae Jeon <linkinjeon@...il.com> writes:
>
>> 2011/9/2 Amit Sahrawat <amit.sahrawat83@...il.com>:
>>> From my opinion both should support the same functionality as the
>>> motive behind this seems to introduce the complete support for utf8.
>>> But, I am surprised to see the behavior changes in the ‘2’ options.
>>> 1)      When using iocharset=”utf8” it makes vfat case sensitive, while
>>> this is not the case with using utf8=1
>>> 2)      Surrogate pair don’t work when using iocharset=”utf8”, because that
>>> traverses a path like this:
>>> xlate_to_uni()-->nls->char2uni()-->char2uni()-->utf8_to_utf32()
>>> After this it returns EINVAL because Surrogate pair correct code is
>>> greater than 0xFFFF (MAX_WCHAR_T – limit which is put)
>>> But this is not the case with utf8=1
>>> There are other places also where I can see usage different due to
>>> usage of char2uni()
>>>
>>> Can someone provide any help on this? Why do we have separate options
>>> for using utf8 and if utf8=1 smoothly supports proper working then why
>>> not discard iocharset=”utf8” ? and if this is not the case
>>> why was utf8=1 introduced?
>>>
>>> Please provide any guidance in this.
>>>
>>> Thanks & Regards,
>>> Amit Sahrawat
>>>
>>
>> I also am wondering this issue for long time.
>> May be, Ogawa will know well.
>
> History is simple. There already was the utf8 option before nls utf8
> module was introduced. And utf8 was introduced for other of FAT.
>
> Well, it doesn't provide case letter conversion table for some
> reasons. But, FAT requires conversion table. For utf8 option, it
> emulates the case conversion by using tables in iocharset= or nls= nls
> module.
>
> NLS infrastructure has several limitation, and to support encoding
> conversion and case letter more fully, it would be better to introduce
> new infrastructure. But it would need not small change.
>
> Thanks.
> --
> OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>
>

Hi. Ogawa.

If the user to use FAT first time, they are confused about this
option, or they may use only iocharset without knowing the utf8
option(there is case sensitive issue). If nls_utf8 is improved such as
adding upper/lower case translation table, supporting surrogate pair
etc.., I want to know whether you can integate only iocharset=utf8
with removing utf8 option.
If done like above my suggetion, user can use only
option(iocharset=utf8) without confusing.

Thanks.
--
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/