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
Spotted when temporarily compiling with -Wwrite-strings. This only goes
a small way towards making the code base -Wwrite-strings–clean. It
introduces no functional changes, and fixes no bugs.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Reviewed-by: nobody
If g_get_home_dir() calculated a NULL home directory (due to $HOME being
unset and /etc/passwd being inaccessible, for example due to an
overly-zealous LSM), it would call g_once_init_leave (&home_dir, NULL),
which would emit a critical and fail to leave the GOnce critical
section. That meant that the following call to g_get_home_dir() would
deadlock in g_once_init_enter().
Fix that by setting the home directory to a made-up value in such cases
(which the documentation handily already explicitly allows).
Thanks to Simon McVittie for the analysis leading to an easy patch.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=773435
This fix undefined symbol link error when building for non-glibc
platform. Applications must link on libintl, it is not a public
dependency of libglib.
On glibc platforms libintl is a not found dependency and is just ignored
by meson, so it doesn't hurt to always have it.
https://bugzilla.gnome.org/show_bug.cgi?id=795406
Fix various warnings regarding unused variables, duplicated
branches etc by adjusting the ifdeffery and some missing casts.
gnulib triggers -Wduplicated-branches in one of the copied files,
disable as that just makes updating the code harder.
The warning indicating missing features are made none fatal through
pragmas. They still show but don't abort the build.
https://bugzilla.gnome.org/show_bug.cgi?id=793729
This builds glib using meson/ninja/ccache with mingw-w64 on a Windows
machine.
The CI scripts expect a gitlab runner to exist with the "win32" tag
which uses the default "cmd" shell by default.
Before running the tests pacman is invoked to update the system
(potentially including bash etc, thus the extra step)
Then a login shell is started with CHERE_INVOKING to not change the
cwd and finally the test script is executed.
https://bugzilla.gnome.org/show_bug.cgi?id=793729
In https://bugzilla.gnome.org/show_bug.cgi?id=794555 the tests for
posix_memalign and stpcpy were extended to catch the case where
the compiler provides an incomplete builtin.
Under MSYS2 the example code still compiles and links while the real usage
of stpcpy fails to build. To prevent the MSYS2 gcc from using the builtin
versions pass -fno-builtin.
https://bugzilla.gnome.org/show_bug.cgi?id=793729
glib enables -Werror=format-nonliteral by default which is triggered
by the embedded gnulib (in vasnprintf.c). Disable that warning
for gnulib alone. The gnulib code is there to handle user provided
format strings, so the warning doesn't add anything anyway.
This fixes the build under MinGW.
https://bugzilla.gnome.org/show_bug.cgi?id=793729
Make it a bit more obvious that the changed properties are provided as
an a{sv}.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Reviewed-by: nobody
The winsock2-using test does work perfectly, however this is a new
thing that didn't exist in autotools-based builds of glib in the past.
Autotools builds used the generic case where values were just defined
to some agreed-upon numbers, and this is what all autotools-glib
binaries and binaries built against autotools-glib (since these
values go into public glibconfig.h header) use. At least one value,
G_POLLIN, is different, thus breaking ABI if some binaries are
built with autotools and the others are built with meson.
Force meson buildscript to use the same G_POLL* constant values
for Windows builds that autotools builds use.
https://bugzilla.gnome.org/show_bug.cgi?id=794687
g_desktop_app_info_load_from_keyfile() refuses to load .desktop files
where the executable doesn't exist. Therefore whether or not the .desktop
file added in commit 148995544 is actually considered during tests depends
on /usr/bin/flatpak being installed. This isn't a safe assumption to make,
so use /bin/sh to test filtering of "prefix" commands.
https://bugzilla.gnome.org/show_bug.cgi?id=795488
The executable name can be a useful bit of information to match on in
searches where it differs from the name (for example because the latter
is localised), but will produce surprising results where the real appli-
cation is executed by a shared binary (for example interpretors like
gjs or python, or sandboxes like flatpak).
Address this by adding a blacklist of binary names that are ignored
in search.
https://bugzilla.gnome.org/show_bug.cgi?id=795488
