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
Language bindings have so far been unable to implement the GListModel
interface because the ::get_item virtual function returns a
non-bindable type (gpointer). The `gpointer` type gets translated into
`void` by G-I meaning that get_item() implementations can't return any
items.
We can set the return type of the get_item() vfunc explicitly to
GObject, which fixes the issue.
This patch also removes the existing (type GObject) annotation on
g_list_model_get_item(), which is necessary because if its return type
matches that of the get_item() vfunc, G-I connects the two and
propagates the 'skip' annotation from one to the other resulting in the
get_item() vfunc being hidden. There's no API break here because the
'skip' annotation makes g_list_model_get_item() invisible to G-I users
anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=787271
This reverts commit 6f8073d44a.
As per further discussion on bug #781598, we can’t do this in GLib,
since fcntl.h is not guaranteed to be present on all Unix systems. Users
of GLib *must* do a header check (for example, using AC_CHECK_HEADERS)
and #include fcntl.h themselves.
Calling g_application_quit() ignores the hold count; this patch adds a
warning to the documentation about other code having a hold on the
application and expecting it to exist.
https://bugzilla.gnome.org/show_bug.cgi?id=737278
Setting a variable and then assigning it to itself avoids
-Wunused-but-set-variable but this specific trick is now caught by
-Wself-assign. Instead, actually use the value or don't bother
assigning it at all:
gdbusauthmechanismsha1.c: #ifdef a var decl to match its actual use use
gdbusauthmechanismsha1.c: call g_ascii_strtoll() in void context
https://bugzilla.gnome.org/show_bug.cgi?id=745723
Setting a variable and then assigning it to itself avoids
-Wunused-but-set-variable but this specific trick is now caught by
-Wself-assign. Instead, actually use the value or don't bother
assigning it at all:
gdbusauth.c: call g_data_input_stream_read_byte() in void context
gdbusauthmechanismsha1.c: value is actually used
gdbusmessage.c: use consistent preprocessor-token protection
gthreadedresolver.c: skip over bytes in data blob
httpd.c: do something useful with the value
https://bugzilla.gnome.org/show_bug.cgi?id=745723
It's not likely that the runtime of a bound language using the
introspection supports running in a process forked by a foreign
library, so that a closure programmed in that language would work
safely.
Any programming environment supporting that would probably have
its own advanced facilities for process spawning, or be able
to access the GLib spawning APIs via raw C bindings (still
represented in the introspection, (skip) only adds a flag)
and do any low-level preparatory dances as necessary for the
forked runtime.
Note that there are other APIs making use of GSpawnChildSetupFunc,
but they are usable with the closure nullified, and we cannot annotate
the closure parameters away because that would break the annotated API
for bindings; accordingly to bug #738176 comment #3, the current bindings'
users are expected to pass null.
It's ugly:
- The core method, g_iconv(), can't be annotated with good semantics.
- The error value of g_iconv_open() is not representable in today's
introspection.
https://bugzilla.gnome.org/show_bug.cgi?id=756128
The length of the caller-allocated (that flag was missing; added as well)
output array is calculated by a formula, so none of the usual array length
annotations apply. The state parameters need to be initialized with zero.
Just let them use the basic API.
https://bugzilla.gnome.org/show_bug.cgi?id=756103
The functions with a GDestroyNotify to the data, or other ill-fitting
allocation semantics, are not currently introspectable.
The effect for the binding user would be that they're unable to
create or destroy a GData list, but they might still have an API
to poke at some data pointers from it.
In fact, none of the functions dealing with GData** or a dataset
location pointer are likely to get sensible bindings anyway;
the annotations added are mostly to avoid memory unsafety
and leaks.
https://bugzilla.gnome.org/show_bug.cgi?id=756470
This supports a subset of ISO 8601 since that is a commonly used standard for
storing date and time information. We support only ISO 8601 strings that contain
full date and time information as this would otherwise not map to GDateTime.
This subset includes all of RFC 3339 which is commonly used on the Internet and
the week and ordinal day formats as these are supported in the GDateTime APIs.
(Minor modification by Philip Withnall to change API versions from 2.54
to 2.56.)
https://bugzilla.gnome.org/show_bug.cgi?id=753459
Make it a bit more obvious when the DTLS methods aren’t implemented by a
particular TLS backend; return an invalid type rather than crashing.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=752240
This was duplicated also in g_object_interface_install_property().
Now, validations specific to classes happen in
validate_and_install_class_property() - specifically, the checks for
the presence of the get_property() and set_property() methods.
https://bugzilla.gnome.org/show_bug.cgi?id=787551
