kern/55427: libhfs cannot find some filenames containing non-ASCII chars

[ageng%alum.mit.edu@localhost]

>Number:         55427
>Category:       kern
>Synopsis:       libhfs cannot find some filenames containing non-ASCII chars
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Jun 28 00:25:00 +0000 2020
>Originator:     Andrew Geng
>Release:        libhfs.c v1.15
>Organization:
>Environment:
Linux delia 5.5.8-arch1-1 #1 SMP PREEMPT Fri, 06 Mar 2020 00:57:33 +0000 x86_64 GNU/Linux
>Description:
I have a directory on what appears to be a case-sensitive HFS+ volume containing subdirectories "Ångstrom" = {'A', 0x030a, 'n', 'g', 's', 't', 'r', 'o', 'm'} and "Azide" (among others). When attempting to list the contents of "Ångstrom":

ls: cannot access 'Ångstrom': No such file or directory

In the tree, Azide is just before Ångstrom; but hfslib_compare_catalog_keys_bc claims that Azide > Ångstrom, so hfslib_find_catalog_record_with_key concludes that Ångstrom is not present.
>How-To-Repeat:
On a case-sensitive HFS+ volume, create a directory structure

somewhere
somewhere/Azide
somewhere/Ångstrom

and attempt to ls somewhere/Ångstrom.

(Untested; we no longer have the machine that wrote this volume.)
>Fix:
Patch exists, submitted to a project that bundles libhfs.c:

https://github.com/0x09/hfsfuse/pull/12

It carries out the FIXME in hfslib_compare_catalog_keys_bc, replacing the use of memcmp with a naive entry-by-entry comparison of the uint16_t arrays. (Because a memcmp on a little-endian machine will compare the lower byte of each uint16_t first.)

The tradeoff is that we lose any clever speedups the compiler has for memcmp. Hopefully that's worth it.