New upstream version 0.32.1upstream/0.32.1

1 files changed, 8 insertions, 6 deletions

diff --git a/src/util/string.vala b/src/util/string.vala
index bf7e605..89424d0 100644
--- a/src/util/string.vala
+++ b/src/util/string.vala
@@ -13,13 +13,13 @@ public inline bool is_string_empty(string? s) {
 }
 
 // utf8 case sensitive compare
-public int utf8_cs_compare(void *a, void *b) {
-    return ((string) a).collate((string) b);
+public int utf8_cs_compare(string a, string b) {
+    return a.collate(b);
 }
 
 // utf8 case insensitive compare
-public int utf8_ci_compare(void *a, void *b) {
-    return ((string) a).down().collate(((string) b).down());
+public int utf8_ci_compare(string a, string b) {
+    return a.down().collate(b.down());
 }
 
 // utf8 array to string
@@ -145,7 +145,7 @@ public string? prepare_input_text(string? text, PrepareInputTextOptions options,
     // Using composed form rather than GLib's default (decomposed) as NFC is the preferred form in
     // Linux and WWW.  More importantly, Pango seems to have serious problems displaying decomposed
     // forms of Korean language glyphs (and perhaps others).  See:
-    // http://trac.yorba.org/ticket/2952
+    // https://bugzilla.gnome.org/show_bug.cgi?id=716914
     if ((options & PrepareInputTextOptions.NORMALIZE) != 0)
         prepped = prepped.normalize(-1, NormalizeMode.NFC);
     
@@ -237,6 +237,8 @@ public string remove_diacritics(string istring) {
             case UnicodeType.ENCLOSING_MARK:
             // Ignore those
                 continue;
+            default:
+                break;
         }
         builder.append_unichar(ch);
     }
@@ -255,7 +257,7 @@ public string to_hex_string(string str) {
 
 // A note on the collated_* and precollated_* methods:
 //
-// A bug report (http://trac.yorba.org/ticket/3152) indicated that two different Hirigana characters
+// A bug report (https://bugzilla.gnome.org/show_bug.cgi?id=717135) indicated that two different Hirigana characters
 // as Tag names would trigger an assertion.  Investigation showed that the characters' collation
 // keys computed as equal when the locale was set to anything but the default locale (C) or
 // Japanese.  A related bug was that another hash table was using str_equal, which does not use