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>
Passing -z nodelete without the shared library flags on Solaris results in
ld: fatal: option '-z nodelete' is incompatible with building a dynamic executable
which causes the configure test to falsely report its not supported.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
https://bugzilla.gnome.org/show_bug.cgi?id=776195
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
It is outdated and no longer effectively used. It was originally in
place to prevent rebuilding generated files (from a tarball) if the
right build tools (awk, Perl, indent) were not available. However, we no
longer use indent, we have hard-required awk for a while, and the only
places the @REBUILD@ substitution was still used were for
glib-genmarshal, which has recently been rewritten in Python (so no
longer depends on whether Perl is available).
Drop the whole lot.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=694723
After the build system rework in commit f9eb9e testgobject fell through
the cracks and was not built since then.
Re-enable it, even if it is currently failing due to commit 31fde56.
(Tweaked by Philip Withnall to add meson.build support.)
https://bugzilla.gnome.org/show_bug.cgi?id=701156
Commit 31fde56 changed the way the private data is laid out in memory by
putting it *before* the instance data to keep the offsets fixed
regardless of the number of many subclasses.
This means that the invariant testgobject was verifying is no longer
true and the failing tests can be safely dropped.
https://bugzilla.gnome.org/show_bug.cgi?id=701156
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
