When doing a level traverse of a GNode with depth of -1, the depth was
implicitly being converted to an unsigned integer. This worked (making
the depth limit G_MAXUINT), but was a bit mystical.
Change g_node_depth_traverse_level() to explicitly take a signed depth
and handle it appropriately.
Coverity issue: #1159465https://bugzilla.gnome.org/show_bug.cgi?id=732003
Otherwise there is a race in finalising the GSourceCallback if one
thread is finishing off a g_main_dispatch() while another thread is
destroying the GSource which owns the GSourceCallback.
A helgrind log:
==21707== Possible data race during write of size 4 at 0x54EACB0 by
thread #12
==21707== Locks held: none
==21707== at 0x4ECC174: g_source_callback_unref (gmain.c:1528)
==21707== by 0x4ECD953: g_main_dispatch (gmain.c:3081)
==21707== by 0x4ECE667: g_main_context_dispatch (gmain.c:3673)
==21707== by 0x4ECE859: g_main_context_iterate (gmain.c:3744)
==21707== by 0x4ECEC7F: g_main_loop_run (gmain.c:3938)
==21707== by 0x41C197: some_thread (some-code.c:224)
==21707==
==21707== This conflicts with a previous write of size 4 by thread #5
==21707== Locks held: 1, at address 0x54CF320
==21707== at 0x4ECC174: g_source_callback_unref (gmain.c:1528)
==21707== by 0x4ECB86F: g_source_destroy_internal (gmain.c:1178)
==21707== by 0x4ECB9D4: g_source_destroy (gmain.c:1227)
==21707== by 0x41CF09: some_other_thread (some-other-code.c:410)
https://bugzilla.gnome.org/show_bug.cgi?id=737677
This removes the use of defined() in a macro expansion, which may not be
portable to some pre-processors. Instead, we hoist the defined check
outside the macro expansion.
https://bugzilla.gnome.org/show_bug.cgi?id=790877
Noticed these were missing when handling bug #733648. Add a few missing
tests to improve coverage.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
There are some GDateTime tests which need to be skipped if changing the
locale fails. Use g_test_skip() to do that, rather than just a
human-readable message.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Specifically controlling the location of this file, rather than simply
using $libdir, allows one to avoid conflicting with the same default
location as the gnulib localcharset module uses.
https://bugzilla.gnome.org/show_bug.cgi?id=346816
On Solaris sigset_t is only defined in /usr/include/sys/signal.h
(included from /usr/include/signal.h) if _XPG4_2 is defined. If
it's not defined, you need to include /usr/include/sys/select.h.
http://bugzilla.gnome.org/show_bug.cgi?id=562334
Some of the documentation linked to information about G_DEBUG already,
but most of it didn’t, and there were no examples. People need obvious
examples.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=790157
Certain compilers warn about unused functions if they are declared in
the header but are not inline. We require `static inline` support from
all compilers now.
Typically, this code will not be used, as the compilers we care about
implement vararg macro support; but this code path can still be hit on
some compilers (probably; unverified).
(Commit message by Philip Withnall.)
https://bugzilla.gnome.org/show_bug.cgi?id=483341
It's a very common pattern to see code that looks like this in
dispose() or finalize() implementations:
if (priv->source_id > 0)
{
g_source_remove (priv->source_id);
priv->source_id = 0;
}
This API allows to accomplish the same goal with a single line:
g_clear_handle_id (&priv->source_id, (GClearHandleFunc) g_source_remove);
Thanks to Emmanuele Bassi <ebassi@gnome.org> for making the patch
generic.
https://bugzilla.gnome.org/show_bug.cgi?id=788489
This will fix a few broken links in the documentation, and shut up a
load of gtk-doc warnings (but certainly not all of them).
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=790015
The carbon framework is deprecated and not really related to OSX's
printf features. Directly test compiler-defined token for the platform
itself rather than that autodetected framework as a proxy.
https://bugzilla.gnome.org/show_bug.cgi?id=731625
It can only fail if there’s been a leak or programmer error, so this is
really unlikely to happen. At least make it obvious something has gone
wrong, though, rather than silently carrying on and returning as if the
reader lock has been acquired.
Do the same for g_rw_lock_writer_lock().
It should be safe to use g_critical() for reporting the problems, since
GRWLock is not used in gmessages.c, and printing a critical seems better
than aborting, just in case we do hit the ‘maximum number of reader
locks’ error code.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=756430
Since journald adds a timestamp, it would be useful to add one to the
stdout/stderr output too — we do not want it to miss out on the
timestamping fun.
Make it blue, because we can.
https://bugzilla.gnome.org/show_bug.cgi?id=769846
Ensures that the hostname returned by g_get_host_name is always UTF8 encoded.
Previously, on Windows, the returned string would be encoded in the
current codepage, if it contained non-ASCII characters.
The unit test for g_get_host_name was updated with a check to ensure
that the hostname is indeed at UTF-8 string.
https://bugzilla.gnome.org/show_bug.cgi?id=789755
This commit adds new W32-only functions to gstdio.c,
and a new header file, gstdioprivate.h.
These functions are:
g_win32_stat_utf8()
g_win32_lstat_utf8()
g_win32_fstat()
and they fill a private structure, GWin32PrivateStat,
which has all the fields that normal stat has, as well as some
extras.
These functions are then used throughout glib and gio to get better
data about the system. Specifically:
* Full, 64-bit size, guaranteed (g_stat() is forced to use 32-bit st_size)
* Full, 64-bit file identifier (st_ino is 0 when normal stat() is used, and still is)
* W32 File attributes (which stat() doesn't report); in particular, this allows
symlinks to be correctly identified
* Full, 64-bit time, guaranteed (g_stat() uses 32-bit st_*time on 32-bit Windows)
* Allocated file size (as a W32 replacement for the missing st_blocks)
st_mode remains unchanged (thus, no S_ISLNK), so when these are given back to
glib users (via g_stat(), for example, which is now implemented by calling g_win32_stat_utf8),
this field does not contain anything unexpected.
g_lstat() now calls g_win32_lstat_utf8(), which works on symlinks the way it's supposed to.
Also adds the g_win32_readlink_utf8() function, which behaves like readlink()
(including its inability to return 0-terminated strings and inability to say how large
the output buffer should be; these limitations are purely for compatibility with
existing glib code).
Thus, symlink support should now be much better, although far from being complete.
A new W32-only test in gio/tests/file.c highlights the following features:
* allocated size
* 64-bit time
* unique file IDs
https://bugzilla.gnome.org/show_bug.cgi?id=788180
Where we were already treating GHashTables as sets, modify them to use
the set-specific APIs g_hash_table_add() and g_hash_table_contains(), to
make that usage more obvious and less prone to being broken.
Heavily based on patches by Garrett Regier <garrettregier@gmail.com>.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=749371
This reverts commit 51f9c95cf240b7de4c1db8e4dcb7e18d72ba0d3c.
It’s changed the set of translatable strings generated in the POT file.
Reverting until a fix can be found for that.
https://bugzilla.gnome.org/show_bug.cgi?id=789170
The warnings issued when dealing with waitpid() raising ECHILD are
somewhat misleading: there are lots of reasons why waitpid() might
fail in this way, and we can't tell which one has happened.
In particular, passing a non-child or a non-pid, waiting for the same
pid elsewhere, or creating a duplicate watch for the same pid would
all fail in the same way.
Consolidate the restrictions into one place, and change all the other
places they were (or should have been!) mentioned to point to
that one place.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=723743
ssize_t is supported widely, but not universally, so use gssize instead.
Currently only one piece of code actually *needs* this change to be compilable
with MSVC, the rest are mostly in *nix parts of the code, but these are changed
too, for symmetry.
https://bugzilla.gnome.org/show_bug.cgi?id=788180
