This reverts commit 3c1902fcf9.
This was accidentally re-added from an old version of the branch before
!265 was merged. It should not have been re-added.
Rearrange the code so we try version 3 first,
falling back to version 2 and then version 1.
We still do a construct-time check to ensure
that we work with unsupported versions.
Note that this also takes care of setting the
initial property values in the version 1 case.
Version 3 of the network monitor portal interface adds
a CanReach method. Use it to implement can_reach.
The docs state that can_reach will either return TRUE
or set an error. So, set an error of G_IO_ERROR_HOST_UNREACHABLE
when the portal returns FALSE for CanReach.
GSettings XML schema files are installed in a well known directory
under Glib's installation directory: `glib-2.0/schemas`. However,
the Glib installation directory might vary, so the exact location of
the schema files might be unknown.
The information regarding this directory has been added to GIO's
pkg-config file, so it can be checked, and also overrided, by using
the command line utility.
Since we now require a C99 compatible printf and use gnulib on Windows,
we also mark our printf functions as gnu_printf. GCC complains about the
Windows specific I64 specifiers we still write to glibconfig.h with the
autotools build.
To fix this switch all I64(x) to ll(x).
This also makes the glibconfig.h output for those macros match the ones
we get when using meson.
__int64 was the 64bit type for Visual Studio before it added support for
"long long" with VS2013. I think this was used to build glib with mingw and
make the result usable for VS 6.0 which didn't support "long long" (??)
Given that newer MSVC links against a different crt and mixing is not supported
and everything supports "long long" nowadays just remove it.
This is also a cleanup for printf format changes needed for #1497
The source callback for a GCancellable should have the cancellable itself
as first argument.
This was not the case, and when this code was hit, we were instead trying
to treat the pointer as a CommunicateState reference and thus wrongly
deferencing it, causing a memory error and a crash.
This is a follow-up to commit 614adf8a75,
which started generating two new files as part of the test; they need to
be cleaned up before distcheck will pass.
Ideally, the test should run a temporary directory and wipe that
directory itself before exiting, but that’s a bit of a big change to
make right now. Deferred to
https://gitlab.gnome.org/GNOME/glib/issues/1495.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
The new typeof() macro version of g_clear_pointer() was evaluating its
pointer argument more than once, meaning any side effects would be
evaluated multiple times.
The existing (other) macro version of g_clear_pointer() was evaluating
its argument exactly once. This mismatch could have confused people or
lead to subtle bugs.
See https://gitlab.gnome.org/GNOME/glib/issues/1494.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
These functions may be OK to leave the G_GNUC_MALLOC attribute on,
because the only valid pointers in the storage areas they return are,
themselves, new pointers.
However, it’s a lot easier to remove the attributes now than to try and
diagnose miscompilations in future. The performance impact of this is
likely to be unmeasurable. If there are performance problems caused by
this, then they can be profiled and fixed case-by-case in future,
bearing in mind the possibility for miscompilation if G_GNUC_MALLOC is
readded.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/1465
These are our most critically incorrect uses of G_GNUC_MALLOC. See the
previous commit for details.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/1465
Thanks to some great investigation by Benjamin Moody, it’s clear that
our documentation and usage of G_GNUC_MALLOC has fallen behind GCC’s
interpretation of the malloc attribute, meaning that recent versions of
GCC could miscompile code which uses G_GNUC_MALLOC incorrectly.
Update the documentation of G_GNUC_MALLOC to match the current GCC
documentation (for GCC 8.2). Following commits will drop our use of
G_GNUC_MALLOC from inappropriate functions.
Specifically, the change in GCC’s interpretation of the malloc attribute
which could cause miscompilation is that returned storage areas are now
assumed to not contain valid pointers — so realloc() cannot have the
malloc attribute, and neither can a function which returns a newly
allocated structure with fields initialised to other pointers.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/1465
Clarify that we actually raise SIGTRAP rather than calling abort(). We
haven’t called abort() since about 2011, when commit
a04efe6afb changed the logic to use
SIGTRAP to make it possible to skip past fatal log messages in the
debugger if they weren’t relevant to the problem being debugged.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/1448
Check for compile warnings when assigning an int64_t* to a long*,
make gint64 a long long if they occur and assigning an int64_t* to
a long long* doesn't.
Modified by Philip Withnall <withnall@endlessm.com> to support Meson as
well as autotools.
https://gitlab.gnome.org/GNOME/glib/issues/972
The size of stat depends on various macros on Windows which leads to
the problem of size mismatches when glib is built with a different configuration
than a program using it.
For example the autotools build defaults to _FILE_OFFSET_BITS=64 and a program
not defining _FILE_OFFSET_BITS will allocate a too small struct on the stack,
leading to stack corruption when glib writes to it.
To make the size the user sees always match the default mingw build define GStatBuf
as _stat64 (same as _FILE_OFFSET_BITS=64) under mingw+64bit.
