gutils.[hc] is a bit of a grab bag, so lets start cleaning
things up by moving all the environment-related functions
into separate genviron.[hc] files.
The private _g_getenv_nomalloc has been moved to its sole caller.
When spawning a child process, it is not safe to call setenv() before
the fork() (because setenv() isn't thread-safe), but it's also not
safe to call it after the fork() (because it's not async-signal-safe).
So the only safe way to alter the environment for a child process from
a threaded program is to pass a fully-formed envp array to
exec*/g_spawn*/etc.
So, add g_environ_getenv(), g_environ_setenv(), and
g_environ_unsetenv(), which act like their namesakes, but work on
arbitrary arrays rather than working directly on the environment.
http://bugzilla.gnome.org/show_bug.cgi?id=659326
Make sure that it calls absolutely nothing that may ever recurse back
into GLib again:
- g_ascii_strcasecmp() is unsafe because it has g_return_if_fail() at
the top. As far as I know, the only ASCII character letter that
would get special treatment here is "i" and that appears in neither
"help" nor "all".
- g_getenv() is very complicated on Windows, so use a simple version
that is sufficient for our purposes.
Now that it's completely safe, we can just call it from g_logv() in the
usual way without all of the hacks.
https://bugzilla.gnome.org/show_bug.cgi?id=660744
Do a substantial rework of the GMutex and GCond APIs.
- remove all of the macro indirection hackery which is no longer needed
since we dropped support for switchable thread implementations
- expose the structure types and add G_MUTEX_INIT and G_COND_INIT
static initialiser macros
- add g_mutex_init() and g_mutex_clear() for use when embedding GMutex
into another structure type and do the same for GCond as well
- avoid infinite recursion hazards by ensuring that neither GCond or
GMutex ever calls back into any other part of GLib
- substantially rework the Windows implementation of GCond and GMutex
to use the SRWLock and CONDITION_VARIABLE APIs present on Windows
2008/Vista and later, emulating these APIs on XP
Remove the explicit thread initialisation functions for g_get_charset(),
g_get_filename_charsets() and g_get_language_names().
Add a lock around one remaining case of access to libcharset (the other
2 cases already have the lock).
Do a proper g_once_init_enter() style initialisation for the GLib
gettext functions.
https://bugzilla.gnome.org/show_bug.cgi?id=658683
Fix various (out) arguments, (allow-none) and (array zero-terminated=1)
for g_spawn_*() and some others.
Some additional fixes by Colin Walters <walters@verbum.org>
https://bugzilla.gnome.org/show_bug.cgi?id=646635
* Since the GLib translations are lazily initialized, we need an
internal wrapper for g_dpgettext() that does the initialization
in the same way as glib_gettext()
* We need to use the glib domain defined by GETTEXT_PACKAGE
rather than than the application's domain.
https://bugzilla.gnome.org/show_bug.cgi?id=644607
Make g_get_user_data_dir() return the CSIDL_LOCAL_APPDATA folder on
Windows, and not CSIDL_PERSONAL. On Windows 7, that corresponds to the
subfolders AppData\Local vs. Documents under the profile ("home")
folder. This matches what Qt does, for instance, and has been widely
requested.
Also make g_get_user_config_dir() return this and not the (roaming)
CSIDL_APPDATA folder. The reason for this change is that it would be
surprising and hard to justify if g_get_user_data_dir() returned the
local application data folder while g_get_user_config_dir() would
return the roaming one. Nothing in the function names or the XDG specs
suggests that any roaming vs. local dichotomy would be involved.
Document the new semantics and the fact that these two functions now
return the same directory on Windows.
Note that in reality, code that really truly wants to support Windows
as well as possible probably will not use these GLib functions anyway,
but Win32 APIs directly to be sure what it is doing...
Should hopefully satisfy complaints in bug #620710 and related bugs.
Don't call LoadLibrary() on shell32.dll or kernel32.dll. kernel32.dll
is always loaded. Shell32.dll is also already loaded as glib links to
functions in it. So just call GetModuleHandle() on them.
For mlang.dll in win_iconv.c and winhttp.dll in gwinhttpvfs.c, always
try loading them from a complete path, from the Windows system
directory.
Use the "tool help" API to enumerate modules in gmodule-win32.c. It is
present in all Windows versions since Windows 2000, which is all we
support anyway. Thus no need to look that API up dynamically. Just
link to it normally. We can bin the fallback code that attempts to use
the psapi API.
2009-02-23 Tor Lillqvist <tml@novell.com>
Bug 570501 - g_win32_get_system_data_dirs uses invalid conversion
of function pointer to object pointer
* glib/gutils.c (g_win32_get_system_data_dirs_for_module): Change
the type of the function's parameter to be explicitly a function
pointer.
* glib/gutils.h (_g_win32_get_system_data_dirs): Modify
declaration and the only caller, the inline
_g_win32_get_system_data_dirs(), accordingly. Add comments
pointing out these are internal GLib functions.
svn path=/trunk/; revision=7899
2008-11-28 Matthias Clasen <mclasen@redhat.com>
Bug 559110 – Do not include libintl.h after glibintl.h
* glib/glibintl.h: Define bind_textdomain_codeset in the DISABLE_NLS
branch. Patch by Peter Kjellerstedt.
* glib/gutil.c: Don't include libintl.h directly.
svn path=/trunk/; revision=7688
2008-09-19 Tor Lillqvist <tml@novell.com>
* glib/gutils.c (_glib_get_dll_directory)
* glib/gspawn-win32.c (do_spawn_with_pipes): Be a bit less
restrictive, look for the helper programs in the same folder where
the GLib DLL is, not necessarily in a "bin" subfolder of the top
GLib installation folder.
svn path=/trunk/; revision=7511
