On non-glibc platforms gettext is provided by extra libintl dependency.
We wrongly thought libintl is an internal dependency and applications
needs to explicitly link on it, but turns out that breaks many
applications and with autotools the .pc generated actually has -lintl in
public "Libs:".
https://bugzilla.gnome.org/show_bug.cgi?id=796085
Do not add support for its subtypes, since all their constructors return
GParamSpec*, and g_param_spec_unref() takes a GParamSpec* rather than a
gpointer — adding G_DEFINE_AUTOPTR_CLEANUP_FUNC() for subtypes of
GParamSpec results in compiler warnings about mismatched parameter
types (GParamSpecBoolean* vs GParamSpec*, for example).
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=796139
These make it easy to steal elements from pointer arrays without having
the array’s GDestroyNotify called on them, similarly to what’s possible
with g_hash_table_steal().
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=795376
If using g_ptr_array_remove*() with a non-NULL GDestroyNotify function,
the value returned will probably be freed memory (depending on what the
GDestroyNotify) function actually does. Warn about that in the
documentation. We can’t just unconditionally return NULL in these cases,
though, since the user might have set the GDestroyNotify to a nifty
function which doesn’t actually free the element; so returning it might
still be valid and useful.
Also add missing (nullable) annotations to that documentation.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=795376
They were almost identically the same. This introduces no functional
changes, but will help with upcoming additions to GPtrArray.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=795376
-z nodelete breaks the libresourceplugin module usage in the resources.c
test, which expects to be able to unload it.
Make the Meson build match what the autotools build does: only pass
glib_link_flags to the headline libraries (glib-2.0, gio-2.0,
gobject-2.0, gthread-2.0, gmodule-2.0) and omit it from all other build
targets.
https://bugzilla.gnome.org/show_bug.cgi?id=788771
The -fstack-protector-strong used in many distributions by default has a
rather drastic slowdown of the fast path in generated _get_type()
functions using G_DEFINE_* macros. The amount can vary by architecture,
GCC version, and compiler flags.
To work around this, and ensure a higher probability that our fast-path
will match what we had previously, we need to break out the slow-path
(registering the type) into a secondary function that is not a candidate
for inlining.
This ensures that the common case (type registered, return the GType id)
is the hot path and handled in the prologue of the generated assembly even
when -fstack-protector-strong is enabled.
https://bugzilla.gnome.org/show_bug.cgi?id=795180
This is a combination of g_hash_table_lookup_extended() and
g_hash_table_steal(), so that users can combine the two to reduce code
and eliminate a pointless second hash table lookup by
g_hash_table_steal().
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=795302
Update our copy of valgrind.h from the Valgrind 3.13 release tarball.
This seems to include fixes for PPC and Solaris. No changes made to the
header file.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=736741
Make it a bit clearer that all lengths passed to GRegex methods are in
bytes (not characters). This is mentioned in the section overview, but
who reads that?
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=748620
On Windows we use gnulib and elsewhere we use glibc or similar.
Also change G_GNUC_PRINTF to use gnu_printf instead of __format__ if
possible because __format__ evaluates to ms_printf under MinGW,
but we use gnulib there and not the system printf.
gnu_printf is only available with GCC>=4.4 and not with clang.
https://bugzilla.gnome.org/show_bug.cgi?id=795569
The existing implementation was completely incorrect (despite the fix in
commit 566e64a66) — it always compared GVariants by pointer, rather than
by value.
Reimplement it to compare them by value where possible, depending on
their type. The core of this implementation is g_variant_compare(). See
the documentation and tests for further details of the new sort order.
This adds documentation and tests.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=795735
gioenumtypes needs to be generated:
In file included from ../../../../external/glib/gio/kqueue/gkqueuefilemonitor.c:37:
In file included from ../../../../external/./glib/gio/glocalfilemonitor.h:25:
In file included from ../../../../external/./glib/gio/gunixmounts.h:24:
../../../../external/./glib/gio/gio.h:86:10: fatal error: 'gio/gioenumtypes.h' file not found
#include <gio/gioenumtypes.h>
^~~~~~~~~~~~~~~~~~~~
https://bugzilla.gnome.org/show_bug.cgi?id=794325
The timezone setup utility of FreeBSD, tzsetup, which is run during the
installation, creates /etc/localtime by copying the chosen timezone file
from /usr/share/zoneinfo. Although it can correctly deal with the case
where /etc/localtime is a symlink, it is not the default and there is no
user interface to change the default copying behaviour.
Fortunately, tzsetup has been modified to write the name of the chosen
timezone to /var/db/zoneinfo in 2009, so we can know the name of the
current timezone by reading it. DragonflyBSD also seems to do the same
thing in its tzsetup.
https://svnweb.freebsd.org/changeset/base/198267https://bugzilla.gnome.org/show_bug.cgi?id=795165
It looks like the coverage generation makes the tests a bit slower and
some are now hitting timeouts. Flaky tests are always more annoying than
slow ones, and we don't know how much resources we get under CI,
so increase the timeout.
https://bugzilla.gnome.org/show_bug.cgi?id=795636
This was causing g_param_value_defaults to return 1
for GVariant values even when the value is clearly
different from the default.
This was showing up as gtk-builder-tool stripping
non-default values for GtkActionable::action-target
from ui files.
Use lcov for both Fedora and MSYS2 to create coverage reports and add a second
ci stage which merges the coverage and creates a html report using genhtml.
In the final stage, which is only run on master, the result is published on
gitlab pages.
https://bugzilla.gnome.org/show_bug.cgi?id=795636
It seems that the test expects g_date_time_format to return formatted
results in English, and there is no setlocale (LC_ALL, "") call in the
file so the test does run in the default C locale. However, gettext
seems to read the value of LC_MESSAGES from the environment by itself.
Even if the value of LC_MESSAGES locale is C because of not calling
setlocale, gettext still translates the name of the month according to
the LC_MESSAGES environment variable, causing g_date_time_format_locale
to fail on the "%b" test case because it cannot convert UTF-8 text
returned by get_month_name_with_day to ASCII.
To avoid the test failure, we set the LC_MESSAGES environment variable
to C before format tests and restore it at the end of the function.
https://bugzilla.gnome.org/show_bug.cgi?id=795165
The return value of g_file_read_link ("/etc/localtime") can
be a relative path in the form of "../usr/share/zoneinfo".
This breaks the prefix check that is performed, and makes
the timezone identifier be "../usr/share/zoneinfo/America/Sao_Paulo",
for example, which breaks other parts of the system.
Fix that by canonicalizing the symlink path if we detect
is it a relative path.
(Tweaked by Philip Withnall <withnall@endlessm.com> to remove a
conditional which was unnecessary.)
https://bugzilla.gnome.org/show_bug.cgi?id=111848
Getting the canonical filename is a relatively common
operation when dealing with symbolic links.
This commit exposes GLocalFile's implementation of a
filename canonicalizer function, with a few additions
to make it more useful for consumers of it.
Instead of always assuming g_get_current_dir(), the
exposed function allows passing it as an additional
parameter.
This will be used to fix the GTimeZone code to retrieve
the local timezone from a zoneinfo symlink.
(Tweaked by Philip Withnall <withnall@endlessm.com> to drop g_autofree
usage and add some additional tests.)
https://bugzilla.gnome.org/show_bug.cgi?id=111848
There is no reason to disable this linker flags, and we are not going to
add this option in our meson build system, so remove it from autotools
too to be on par. If anyone complains with a valid use-case we can add
them back.
Keeping -Bsymbolc for now because it is used for refdbg and Debian has a
package that build glib with that flag.
https://bugzilla.gnome.org/show_bug.cgi?id=788771
It inserted the new items one position after the given one and inserted all new items
at the same position resulting in the items being in the reverse order of the
input array.
It was decided to make these behavioural changes because this function has according to
https://codesearch.debian.net/search?q=g_list_store_splice only one real user (nautilus)
and it didn't do what one would expect from reading the documentation.
https://bugzilla.gnome.org/show_bug.cgi?id=795307
It was previously a copy–paste of G_VALUE_COLLECT, which is wrong,
because it’s the inverse function of G_VALUE_COLLECT. Document that, so
the whole thing is a little less confusing (but by no means perfect).
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Reviewed-by: nobody
All those logging functions already add a newline to any message they
print, so there’s no need to add a trailing newline in the message
passed to them.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Reviewed-by: nobody
The critical omission from the GClosure documentation is that you need
to call g_closure_set_marshal() when implementing a custom GClosure.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Reviewed-by: nobody
The monitor_path comes from g_file_get_path(), so should be freed with
g_free() rather than free(). This makes no difference because they are
the same function in practice, but using free() is a bit confusing.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Reviewed-by: nobody
This continues one of the const-correctness fixes from the previous
commit (it needed some more transitive fixes), and reverts another of
them, since it was over-zealous.
This fixes CI failure: https://gitlab.gnome.org/GNOME/glib/-/jobs/27125.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Reviewed-by: nobody
