From: "Pali Rohár" <pali@kernel.org>
To: Al Viro <viro@zeniv.linux.org.uk>
Cc: Namjae Jeon <namjae.jeon@samsung.com>,
Sungjong Seo <sj1557.seo@samsung.com>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/4] exfat: Simplify exfat_utf8_d_hash() for code points above U+FFFF
Date: Wed, 18 Mar 2020 10:32:51 +0100 [thread overview]
Message-ID: <20200318093251.bgxd3l5om4zlm3br@pali> (raw)
In-Reply-To: <20200318000925.GB23230@ZenIV.linux.org.uk>
On Wednesday 18 March 2020 00:09:25 Al Viro wrote:
> On Tue, Mar 17, 2020 at 11:25:52PM +0100, Pali Rohár wrote:
> > Function partial_name_hash() takes long type value into which can be stored
> > one Unicode code point. Therefore conversion from UTF-32 to UTF-16 is not
> > needed.
>
> Hmm... You might want to update the comment in stringhash.h...
Well, initially I have not looked at hashing functions deeply. Used
hashing function in stringhash.h is defined as:
static inline unsigned long
partial_name_hash(unsigned long c, unsigned long prevhash)
{
return (prevhash + (c << 4) + (c >> 4)) * 11;
}
I guess it was designed for 8bit types, not for long (64bit types) and
I'm not sure how effective it is even for 16bit types for which it is
already used.
So question is, what should we do for either 21bit number (one Unicode
code point = equivalent of UTF-32) or for sequence of 16bit numbers
(UTF-16)?
Any opinion?
next prev parent reply other threads:[~2020-03-18 9:32 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20200317222604epcas1p1559308b0199c5320a9c77f5ad9f033a2@epcas1p1.samsung.com>
2020-03-17 22:25 ` [PATCH 0/4] Fixes for exfat driver Pali Rohár
2020-03-17 22:25 ` [PATCH 1/4] exfat: Simplify exfat_utf8_d_hash() for code points above U+FFFF Pali Rohár
2020-03-18 0:09 ` Al Viro
2020-03-18 9:32 ` Pali Rohár [this message]
2020-03-28 23:40 ` Pali Rohár
2020-03-17 22:25 ` [PATCH 2/4] exfat: Simplify exfat_utf8_d_cmp() " Pali Rohár
2020-03-17 22:25 ` [PATCH 3/4] exfat: Remove unused functions exfat_high_surrogate() and exfat_low_surrogate() Pali Rohár
2020-03-17 22:25 ` [PATCH 4/4] exfat: Fix discard support Pali Rohár
2020-03-17 23:20 ` [PATCH 0/4] Fixes for exfat driver Namjae Jeon
2020-04-15 8:01 ` Pali Rohár
2020-04-15 23:43 ` Namjae Jeon
2020-04-03 2:18 [PATCH 1/4] exfat: Simplify exfat_utf8_d_hash() for code points above U+FFFF Kohada.Tetsuhiro
2020-04-03 20:40 ` Pali Rohár
2020-04-06 9:37 ` Kohada.Tetsuhiro
2020-04-07 10:06 ` Pali Rohár
2020-04-08 3:59 ` Kohada.Tetsuhiro
2020-04-08 9:04 ` Pali Rohár
2020-04-13 8:13 ` Kohada.Tetsuhiro
2020-04-13 10:10 ` Pali Rohár
2020-04-14 9:29 ` Kohada.Tetsuhiro
2020-04-14 9:47 ` Pali Rohár
2020-04-15 7:46 ` Kohada.Tetsuhiro
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200318093251.bgxd3l5om4zlm3br@pali \
--to=pali@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=namjae.jeon@samsung.com \
--cc=sj1557.seo@samsung.com \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).