[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <asia2RnsWgGjiHZV@localhost>
Date: Fri, 9 Oct 2026 09:47:13 +0200
From: i262jq@...se
To: musl@...ts.openwall.com
Subject: Re: fnmatch: invalid multibyte sequence in the string is
taken as end of string ("" matches "\xff" in UTF-8 locales)
Hello Rich,
On Thu, Oct 08, 2026 at 09:46:42PM -0400, Rich Felker wrote:
> "All text is UTF-8" was one of the founding principles of musl.
This is fully sound.
OTOH the idea that "filenames are text" is relatively new.
Filenames are just keys in a hierarchical database. their meaning for
the kernel does not e.g. depend on any "lexical order".
fnmatch() is a tool for filtering of file names.
It seems counterproductive if the filtering *must* strictly be done in
a context of a certain encoding (not necessarily known to or enforced
by the kernel, nor by the filenames' creators).
I feel this introduces a confusion between analysis and presentation.
Encoding defines presentation of text. To the contrary, for
analysis/filtering a (single) assumed encoding is at best a hint,
if we analyze data like encountered file names.
That's why the presence of the C locale is appreciated. There the
application can analyze the found binary strings from the point of view
of (at wish multiple) different text encodings, or just use the result
without treating it as "text".
Otherwise it might possibly be useful to treat locale in fnmatch()
as a hint, not as a syntax assumption?
My 2c
i262jq
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
