In the case that the "HOME" environment variable is set (as it is under
normal circumstances), we don't really need to be opening /etc/passwd.
For historical reasons (ie: how we used to ignore $HOME) and due to the
grouping of many unrelated things together (reading username, hostname,
home directory, tmpdir, etc.) into one function we were still opening
/etc/passwd in g_get_home_dir(), even if $HOME was set.
Since earlier commits removed code from it, all that remains in
g_get_any_init_do() is the logic for dealing with $HOME and reading the
password database.
We now split the logic to deal with $HOME into g_get_home_dir(). With
only the password database functionality remaining, g_get_any_init_do()
is renamed to g_get_user_database_entry() and modified not to set global
variables but rather return a struct. If g_get_home_dir() cannot find
$HOME, it falls back to calling g_get_user_database_entry() and using
the home directory from there.
Use of the 'g_utils_global' lock is further reduced by using
g_once_init_enter() to protect the critical sections in each of
g_get_user_database_entry() and g_get_home_dir().
Finally, the g_get_user_name() and g_get_real_name() functions are
modified to use the new regime.
Some code was directly calling g_get_any_init() and then expecting to be
able to use the static 'g_home_dir' variable directly. Change these
over to g_get_home_dir() instead.
This is a source-compatible change and only breaks ABI with respect to
truly ancient binaries (and those binaries are already broken for other
reasons).
Back in the day, functions like g_get_user_name() used to return strings
in the system codepage instead of utf8 (as they do today).
It was decided at some point to change these functions to return utf8,
breaking source compatibility but keeping ABI compatibility. This was
done by exporting new symbols with names like g_get_user_name_utf8() and
using a #define of the old name over to the new name (so that newly
compiled code would link against the _utf8 version, but old binaries
would continue to use the non-utf8 variant).
Meanwhile, glib has undergone several ABI breaks on Windows since, so
those old binaries don't work anymore.
Start to clean up this mess by removing the #define renaming. New
binaries calling g_get_user_name() will now link against
g_get_user_name() and it will return utf8.
We must keep the functions like g_get_user_name_utf8() for binary
compatibility with recently built programs (ie: ones built with the
renaming). Nobody should have ever been calling these directly and of
course they can return utf8, so just add them as internal wrappers in the
.c file and declare them _GLIB_EXTERN there.
One day, if we feel like breaking Windows ABI again, we can finish the
cleanup by dropping the wrappers.
If there are options that need their names to be aliased, keep track
of that internally rather than modifying the passed-in GOptionGroup
(and leaking strings in the process).
https://bugzilla.gnome.org/show_bug.cgi?id=682560
The default handler test was not unsetting the log handler that
gets installed by GTest, which causes the log messages to be duplicated
on stdout if --verbose or --tap are passed. This in turn can make some
of the non-match checks fail. Since we are already using g_test_trap_fork,
we can just unset the handler in the child.
GHashTable remains a set for as long as all of the keys are exactly
equal (in pointer value) to all of the values. We check this by
comparing keys to values when we do inserts.
Unfortunately, when doing g_hash_table_insert() when a key is already in
the table, the old key pointer value is kept, but the new value pointer
is used. Now we have a situation where a key pointer is unequal to a
value pointer, but we were not treating this case properly.
Fix that.
https://bugzilla.gnome.org/show_bug.cgi?id=692815
While compiling, libtool will say that undefined symbols are not allowed, and
will refuse to make you a dll. This is only one line, easy to miss. And it
doesn't prevent `make' from completing successfully.
The code this patch adds is from other Makefile.am files that use
$(no_undefined). It's absence in gio is, most likely, an oversight.
Fixes#692058
Since this is a new API this cycle it's a good time to add a doc comment
explicitly declaring that a confusing issue that could be resolved
either way has no specific defined behaviour.
This may allow us some additional freedom in future GMainContext work or
we may decide that one behaviour is more desirable than the other.
The flowinfo and scope_id fields of struct sockaddr_in6 are in host
byte order, but the code previously assumed they were in network byte
order. Fix that.
This is an ABI-breaking change (since before you would have had to use
g_ntohl() and g_htonl() with them to get the correct values, and now
that would give the wrong values), but the previous behavior was
clearly wrong, and no one ever reported it, so it is likely that no
one was actually using it.
https://bugzilla.gnome.org/show_bug.cgi?id=684404
There are two benefits to this:
1) We can centralize any operating system specific knowledge of
close-vs-EINTR handling. For example, while on Linux we should never
retry, if someone cared enough later about HP-UX, they could come by
and change this one spot.
2) For places that do care about the return value and want to provide
the caller with a GError, this function makes it convenient to do so.
Note that gspawn.c had an incorrect EINTR loop-retry around close().
https://bugzilla.gnome.org/show_bug.cgi?id=682819
Ok, this function was just an awful mess before. Now the problem
domain is not trivial, and I won't claim this new code is *beautiful*,
but it should fix the bug at hand, and be somewhat less prone to
failure for the next person who tries to modify it. There's only one
unref call for each object now.
https://bugzilla.gnome.org/show_bug.cgi?id=692408
