This is a partial change of the previous work[0].
On 64 bit Android since android-23, 'handle = dlopen(NULL); dlsym(handle)'
doesn't work. Instead, only 'dlsym(RTLD_DEFAULT)' returns a valid pointer.
However, RTLD_DEFAULT is defined as '(void *) 0x0' on 64bit Android which
is usually used for invalid value so this patch allows the specific case.
[0] 0d81bb4e31https://bugzilla.gnome.org/show_bug.cgi?id=788270
Suggest defining it for all code — for applications as well as for
libraries. This allows G_MESSAGES_DEBUG=my-app to be used to filter out
all messages from libraries which it uses, for example.
https://bugzilla.gnome.org/show_bug.cgi?id=777956
Include a line in the documentation for g_warning(), g_error(), g_critical()
and g_debug() mentioning that the messages passed to them typically should not
be translated.
Closes: https://bugzilla.gnome.org/show_bug.cgi?id=679467
The return value from g_get_user_special_dir() might be NULL. Safest to
use g_strcmp0() uniformly everywhere.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=661442
They return floating references. The convention established by GVariant
is to annotate these as (transfer none) so that the caller does a
ref+sink on them, rather than just a ref.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=677233
If gio open exits before the program it starts fully activates, then
the dbus-daemon may avoid doing the activating method call.
This commit works around the problem by pinging the activated application,
and waiting for a reply.
Same workaround is used in gtk-launch and was used in gvfs-open before
it was replaced by gio open.
https://bugzilla.gnome.org/show_bug.cgi?id=780296
g_printf(), g_fprintf(), g_sprintf(), g_vprintf(), g_vfprintf(),
() and g_vasprintf() require gprintf.h to be explicitly included
in order to be used. This patch adds a reminder in each function's
documentation abstract.
https://bugzilla.gnome.org/show_bug.cgi?id=760716
g_snprintf() and g_vsnprintf() declarations were moved and
don't require gprintf.h to be included anymore but g_vasprintf()
is and requires gprintf.h to be explicitly included.
https://bugzilla.gnome.org/show_bug.cgi?id=760716
Lines starting with "Bail out!" are special TAP syntax: they mark
the entire test execution (one binary or script) as failed, and stop
processing. Automake's parallel test harness knows this, and will print
the diagnostic in the test results, leading to clearer output.
Without this change, having changed glib/tests/bytes.c to emit a
spurious g_warning():
ERROR: bytes - too few tests run (expected 15, got 0)
ERROR: bytes - exited with status 133 (terminated by signal 5?)
With this change, it's clearer what has happened:
ERROR: bytes - Bail out! FATAL-WARNING: I broke this as a demonstration
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=788467
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
This avoids warnings when compiling with -Wconversion on 32-bit
architectures, as the conversion to (long double) is not necessarily
lossless. We don’t care about that, though, since the actual comparison
was done with the correct types, and g_assertion_message_cmpnum() is
only used to print failure information.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=788385
In GUINT64_TO_BE(), for example, when compiling with -Wsign-conversion,
we get a warning due to an implicit cast from (gint64) to (guint64) when
passing the argument to __builtin_bswap64().
According to the GCC documentation, __builtin_bswap64() takes an
unsigned argument:
https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html
Cast the input appropriately.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=788384
Commit 53ed180 improved mtab processing, however, also introduced bug
in code obtaining mount points. mtab was used by mistake also for
g_unix_mount_points_get implementation, which is obviously wrong and
fstab has to be used instead...
https://bugzilla.gnome.org/show_bug.cgi?id=781867
Fix get_mounts_timestamp() to not use a stat'ed mtime for /proc/ files.
Instead, use mount_poller_time if /proc/ watch is running, or otherwise
return a new generated timestamp to always assume mounts-changed, which
is safer than previous behaviour of always assuming mounts-not-changed
(as mtime never changes for /proc/ files when queried from the same
process).
We say it's safer because allows caches depending on:
g_unix_mounts_get(&time_read)
g_unix_mounts_changed_since()
to drop possibly outdated/duplicated values, as that was the case for the
GIO mounts cache used in gio/glocalfile.c which provides mount info for
g_file_query_filesystem_info() call, as described in below referenced bug.
This fix complements related commit bd9e266e11https://bugzilla.gnome.org/show_bug.cgi?id=787731
Add testcase for function g_file_query_filesystem_info()
reporting outdated info for "filesystem::readonly" attribute
when said attribute was different in a previous mounted
partition in the same device (as GIO maintains a mounts cache
per 'st_dev' stat() member).
To trigger a mount operation, testcase uses program 'bindfs'
instead of 'mount --bind' as bindfs does not require root
privileges. And 'fusermount -u' command is used to unmount said
bindfs mount.
As a reference in Fedora, 'bindfs' is installed from 'bindfs'
package and 'fusermount' from 'fuse' package (this one is installed
by default as being part of 'System Tools' group).
The test creates a directory with a file in it, then mounts it
readonly over another directory (the mountpoint), it then checks
that g_file_query_filesystem_info() for the file in it indeed reports
"filesystem::readonly" as TRUE. Then unmounts and mounts again this
time rw (not readonly), it then checks again if g_file_query_filesystem_info()
is reporting "filesystem::readonly" as TRUE, if that's the case, it
confirms the bug by opening said file in write mode.
Testcase is only added for Unix builds.
https://bugzilla.gnome.org/show_bug.cgi?id=787731
This reverts commit 8028494335.
Adding (array length=…) to a gchar* parameter causes the GIR file to
contain an array of strings, rather than an array of characters. While
we fix GIR, revert those changes.
Some of the other changes in the file (which have an explicit
(element-type) already) are fine.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=765063
The previous commit to glib/glibconfig.h.win32.in, though it improves
the state of GLib and fixes bugs, cannot be used as a drop-in
replacement for code that builds against the previous
glib/glibconfig.h(.win32.in) that were build using the Visual Studio
projects. Change the DLL names as a result so that the likelihood of
problems caused by replacing existing GLib DLLs can be reduced--code
that was built against previous GLib MSVC builds should be rebuilt, so
that things will work with the newer DLLs, instead of depending on the
older DLLs.
Note that if Visual Studio builds are done through Meson, existing code
that link against GLib should be rebuilt as well, for the same reason.
DLLs built with the Visual Studio projects from 2.55.0 onwards should be
compatible with the ones that are built with Visual Studio via Meson.
Make the entries in here more consistent with what Meson produces with
its Visual Studio builds. Also fix the macros [GSIZE|GSSIZE]_TO_[LE|BE]
for x64 builds.
We should still let people building via the MSVC projects decide whether
they use the bundled PCRE sources for building GLib. Accidentally
changed it in the previous commit.
Update config.h.win32.in to match closely to what Meson will produce for
the various Visual Studio versions (2008~2017), as it seems that Meson
produces a better config.h for our MSVC builds of GLib.
One of the major changes in this is that all Visual Studio builds
(either through Meson, which is already so, or via the existing
projects) is that the built binaries will require Windows 7 or later,
so that we let people know early on in a cycle that MSVC builds of
2.55.0 and later will definitely need Windows 7 or later.
The m4 and bash completion items are usable and relevant
depending on the host system's configuration. So, we check for the
presence of the programs that these items depend on, and only install
them when those programs are found.
For the Valgrind suppression files, we don't install them on Windows as
Valgrind is currently not supported on Windows.
Als fix the path where the GDB helpers are installed, as the path is
incorrectly constructed.
This will fix the "install" stage when building on Visual Studio at
least as there are some post-install steps that are related to them,
which will make use of these programs.
https://bugzilla.gnome.org/show_bug.cgi?id=783270
Some of the Meson build files are not dist'ed by 'make dist', which are
reqired for things to work, and there was a missing '\' that cause some
of the meson.build files under tests/ not to be disted.
https://bugzilla.gnome.org/show_bug.cgi?id=783210
They are not supported by Visual Studio, so only define them in
glibconfig.h.in when not on Visual Studio. Fixes builds of GTK+-2.x
against Meson/MSVC builds of GLib.
https://bugzilla.gnome.org/show_bug.cgi?id=783270
I’m unsure what the original reasoning for returning TRUE by default
from supports_dtls was, but it is not backwards-compatible. If a
pre-existing GTlsBackend implementation never implements the
supports_dtls vfunc, the supports_dtls() method will magically return
TRUE rather than FALSE.
Since any backend which does implement DTLS should be implementing the
supports_dtls vfunc (and no DTLS-supporting backends have actually been
merged yet; see bug #697908), it seems safer to make this slight API
break in the name of backwards compatibility than to leave it as
returning TRUE incorrectly.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=787485
