harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Muir <rcm...@gmail.com>
Subject Re: [classlib][luni] String.toLowerCase/toUpperCase incorrect for supplementary characters (HARMONY-6649)
Date Fri, 24 Sep 2010 05:13:42 GMT
On Fri, Sep 24, 2010 at 1:06 AM, Tim Ellison <t.p.ellison@gmail.com> wrote:

> On 24/Sep/2010 05:28, Robert Muir wrote:
> > On Fri, Sep 24, 2010 at 12:10 AM, Tim Ellison <t.p.ellison@gmail.com>
> wrote:
> >> Thanks.  Seems strange since it could obviously produce some 'unusual'
> >> results.  In this case, computing a hashCode, it likely doesn't matter
> >> if the result is a bogus string.
> >>
> >>
> > Do you have an example where the result would be unusual for a filename?
>
> I'm not thinking it would be unusual for being interpreted as file path
> (e.g. it won't introduce a '/' or anything like that) but that the
> result would not be the lowercase equivalent in the locale that the user
> created the filename.
>
>
but case-sensitive filenames (such as windows) don't use locale-dependent
comparisons?
they implement locale-independent case-folding. for example if i have a
file "σ.txt", I cannot create "ς.txt". (I just tried)
Both of these files are already in lowercase.

The interesting question is: how does hashCode() relate? Because a hashcode
based upon String.toLowerCase(Locale.ENGLISH) would return different
hashcodes for these two filenames, but with UCharacter.foldCase(), it would
be the same.

-- 
Robert Muir
rcmuir@gmail.com

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message