path: root/utils/locale.h
diff options
authorJohn Mark Bell <>2008-05-13 14:37:44 +0000
committerJohn Mark Bell <>2008-05-13 14:37:44 +0000
commit23fb72ea6b7324d78df4b89a37566bfed6d77fbb (patch)
tree52b575661394b487e813fcd11bce3a5cdbff00a0 /utils/locale.h
parent74a1095cd6cf6c8f3b42db14e1d3352eb019d335 (diff)
The core code has always assumed a locale of "C".
Do not change the locale globally, else things will break in weird and wonderful ways. Introduce utils/locale.[ch], which provide locale-specific wrappers for various functions (currently just the <ctype.h> ones). Fix up the few places I can see that actually require that the underlying locale is paid attention to. Some notes: 1) The GTK frontend code has not been touched. It is possible that reading of numeric values (e.g. from the preferences dialogue) may break with this change, particularly in locales that use something other than '.' as their decimal separator. 2) The search code is left unchanged (i.e. assuming a locale of "C"). This may break case insensitive matching of non-ASCII characters. I doubt that ever actually worked, anyway. In future, it should use Unicode case conversion to achieve the same effect. 3) The text input handling in the core makes use of isspace() to detect word boundaries. This is fine for western languages (even in the C locale, which it's currently assuming). It will, however, break for CJK et. al. (this has always been the case, rather than being a new issue) 4) text-transform uses locale-specific variants of to{lower,upper}. In future this should probably be performing Unicode case conversion. This is the only part of the core code that makes use of locale information. In future, if you require locale-specific behaviour, do the following: setlocale(LC_<whatever>, ""); <your operation(s) here> setlocale(LC_<whatever>, "C"); The first setlocale will change the current locale to the native environment. The second setlocale will reset the current locale to "C". Any value other than "" or "C" is probably a bug, unless there's a really good reason for it. In the long term, it is expected that all locale-dependent code will reside in platform frontends -- the core being wholly locale agnostic (though assuming "C" for things like decimal separators). svn path=/trunk/netsurf/; revision=4153
Diffstat (limited to 'utils/locale.h')
1 files changed, 42 insertions, 0 deletions
diff --git a/utils/locale.h b/utils/locale.h
new file mode 100644
index 000000000..ebe9a9063
--- /dev/null
+++ b/utils/locale.h
@@ -0,0 +1,42 @@
+ * Copyright 2008 John-Mark Bell <>
+ *
+ * This file is part of NetSurf,
+ *
+ * NetSurf is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * NetSurf is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see <>.
+ */
+/** \file
+ * Locale-specific variants of various routines (interface)
+ */
+/* <ctype.h> functions */
+int ls_isalpha(int c);
+int ls_isalnum(int c);
+int ls_iscntrl(int c);
+int ls_isdigit(int c);
+int ls_isgraph(int c);
+int ls_islower(int c);
+int ls_isprint(int c);
+int ls_ispunct(int c);
+int ls_isspace(int c);
+int ls_isupper(int c);
+int ls_isxdigit(int c);
+int ls_tolower(int c);
+int ls_toupper(int c);