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
fstype is a const char*, and is passed to
g_file_info_set_attribute_string(), which takes a copy of it. There’s no
need to g_strdup() the FS type from various statfs/statvfs buffers
beforehand, given that the buffers are valid for the duration of this
function.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=679347
It's theoretically possible that we could have a case where this would
actually return NULL, but it's difficult to imagine a valid program that
would contain such a case.
Add an explicit assert here to quiet up static analysis.
See the bug for more discussion.
Coverity CID: 1159477
https://bugzilla.gnome.org/show_bug.cgi?id=730296
This adds g_file_load_bytes() to make it more convenient to
load the contents of a GFile as GBytes.
It includes a special casing for gresources to increase the
chances that the GBytes directly references the embedded data
instead of copying to the heap.
https://bugzilla.gnome.org/show_bug.cgi?id=790272
In the vast majority of cases, we can avoid temporary
allocations for paths in g_resources_enumerate_children().
In the case we need to add a suffix "/", we can usually just
build the path on the stack. In other cases, we can completely
avoid the strdup, which appears to only have been added for
readability. If the path is really long, we fallback to doing
what we did before, and use g_strconcat().
In the case of Builder, this saved 5.3mb of temporary
allocations in the process of showing the first application
window.
https://bugzilla.gnome.org/show_bug.cgi?id=790275
Previously, the path canonicalization for resources had liberal use of
strlen() and memmove() while walking through the path. This patch avoids
any secondary strlen() and removes all use of memmove().
A single allocation is created up front as we should only ever need one
additional byte more than then length of the incoming path string.
To keep the implementation readable, the mechanics are kept in external
functions. memrchr() was not used due to its lack of portability.
This is faster in every test case I've tested. Paths that contain
relative ../ have the most speedup.
https://bugzilla.gnome.org/show_bug.cgi?id=790310
The Python version was added for the Meson build, but we might as well
use it from autotools too, since it does exactly the same thing as the
Perl version (modulo not including a trailing linebreak, but that
doesn’t matter).
Works fine with Python 2.7 or Python 3.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=790147
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
Uris may be altered by the following code, which breaks xdg-open:
file = g_file_new_for_commandline_arg (arg[i])
uri = g_file_get_uri (file);
Examples of possible uri changes:
mailto:email -> mailto:///email
magnet:?xt=urn:hash -> magnet:///?xt=urn:hash
ssh://user@host -> sftp://user@host
This patch causes that uris aren't preprocessed for locations with
scheme, however absolute and relative paths are still preprocessed.
https://bugzilla.gnome.org/show_bug.cgi?id=779182
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
