Re: [RFA/libiberty] Darwin has case-insensitive filesystems

[Corinna Vinschen <vinschen@redhat.com>]

On Jun 15 11:58, Mark Kettenis wrote:
> > Date: Wed, 15 Jun 2011 10:22:36 +0200
> > From: Corinna Vinschen <...>

Please do not quote my email address in the body of your message.
Thank you.

> > IMHO it's actually a pity that the filename comparison behaves differently
> > on different systems.  I think it would make sense to behave identical on
> > all systems.  What about this:  Always search case-sensitive.  If file has
> > been found, return.  Otherwise, search case-insensitive.
> 
> Over my dead body.  On a proper operating system filenames are
> case-sensitive.  Your suggestion would create spurious matches.

Indeed.  Probably the case sensitivity should not be hardcoded in a
low-level function at all.  The application should decide if it wants
case-sensitive or case-insensitive filename comparison.  This way,
the comparison could be based on OS, filesystem, or user choice.

> Even on case-preserving filesystems I'd argue that treating them as
> case-sensitive is still the right approach.  If that creates problems,
> it means somebody was sloppy and didn't type the proper name of the
> file or some piece of code in the toolchain arbitrarily changed the
> case of a filename.  I don't mind punishing people for that.  They
> have to learn that on a proper operating system file names are
> case-sensitive!

I wasn't aware that gcc, gdb, and other tools using libiberty are
supposed to punish people for the features of the OS they are working
on.  At one point I actually thought they were supposed to *help*
developers.  I seem to be wrong.

> > Talking about case-insensitive comparison, the filename_cmp and
> > filename_ncmp functions don't work for multibyte codesets, only for
> > singlebyte codesets.  Given that UTF-8 is standard nowadays, shouldn't
> > these functions be replaced with multibyte-aware versions?
> 
> For UTF-8, that isn't necessary.  Normal string manipulation functions
> work just fine on them, since UTF-8 strings don't contain any embedded
> NUL characters.  It's only when you try to be too clever about
> case-insensitivity that you run into problems.

If you read the text you're replying to once more, you see that I'm
explicitely talking about case-insensitive comparison.  In that case,
the functions won't work correctly, unless you use a singlebyte codeset.
The tolower function on a single byte just doesn't make sense in
multibyte charsets.  The right thing to do would be something along
the lines of

    mbstowcs (wide_a, a);
    mbstowcs (wide_b, b);
    return wcscasecmp (wide_a, wide_b);

> > Along the same lines, the entire set of safe-ctype functions only
> > work for ASCII and EBCDIC...
> 
> That really should only matter for displaying filenames.

It matters for case-insensitive filename comparison as well.

> Anyway.  I really don't care how deep a hole people have dug for
> themselves in trying to support Windows in all its various broken
> configurations.

I can't help but notice that you seem to have a strained relationship to
Windows.  However, if you read the OP again, you'll notice that the patch
was supposed to help developers on MacOS, not Windows.  For Windows the
function already performs case-insensitive comparison, albeit wrong.


Corinna

-- 
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat