FilePath: Remove most of ToWStringHack, adding a LossyDisplayName()

chrome/browser/download/download_item.cc

Index: chrome/browser/download/download_item.cc
diff --git a/chrome/browser/download/download_item.cc b/chrome/browser/download/download_item.cc
index 620828b90c536bf57467ead14a67b7c248132926..eb8533788709b7615477fa0d11b026ef8987976b 100644
--- a/chrome/browser/download/download_item.cc
+++ b/chrome/browser/download/download_item.cc
@@ -486,7 +486,7 @@ bool DownloadItem::MatchesQuery(const string16& query) const {
   if (url_formatted.find(query) != string16::npos)
     return true;
 
-  string16 path(l10n_util::ToLower(WideToUTF16(full_path().ToWStringHack())));
+  string16 path(l10n_util::ToLower(full_path().LossyDisplayName()));
   if (path.find(query) != std::wstring::npos)

[Mark Mentovai, 2011/02/04 19:26:58]

string16::find doesn’t seem like the right way to search or compare UTF-16 text.

[evanm, 2011/02/04 19:37:12]

I guess for strict substring it's ok, because extension bytes never match
non-extension bytes?  (... here, search for "string searches" on
http://en.wikipedia.org/wiki/UTF-16/UCS-2 )

In any case, I am not changing the logic here.  Though I might as well fix this
to use string16::npos while I'm here.

[Avi (use Gerrit), 2011/02/04 19:42:32]

For strict substring, this is valid.

[Mark Mentovai, 2011/02/04 19:49:32]

evanm wrote:
I think that discussion only considers whether UTF-16 surrogates pose a problem
for string searches. They don’t. But Unicode’s full of other surprises. What
about composite characters? Are the strings already canonical? Should 0065 0301
compare equal to 00e9?

http://en.wikipedia.org/wiki/Unicode#Ready-made_versus_composite_characters

http://en.wikipedia.org/wiki/Canonical_equivalence

[evanm, 2011/02/04 19:58:50]

Good point.  Filed a bug, added a link.

     return true;