When debug output is enabled then certain messages will be logged to
stdout. stdout however is block buffered by default when it isn't going
to a TTY meaning that debug logging will not be flushed out properly
when it is being redirected. One example of this happening may be tests
that rely on parsing g_debug messages.
Adding an explicit fflush ensures all log messages will reach the output.
https://bugzilla.gnome.org/show_bug.cgi?id=792432
This is a variant of g_file_get_path() which returns a const string to
the caller, rather than transferring ownership.
I've been carrying `gs_file_get_path_cached()` in libgsystem and it
has seen a lot of use in the ostree and flatpak codebases. There are
probably others too.
I think language bindings like Python/Gjs could also use this to avoid
an extra malloc (i.e. we could transparently replace
`g_file_get_path()` with `g_file_peek_path()`.
(Originally by Colin Walters. Tweaked by Philip Withnall to update to
2.56, change the function name and drop the locking.)
https://bugzilla.gnome.org/show_bug.cgi?id=767976
gdbus-codegen's options only allow a simultaneous header and source
code generation.
A `--header` and `--body` options have been added along with the
`--output` option which allow separate C header and code
generation.
These options cannot be used in addition to the old options such
as `--generate-c-code`, `--generate-docbook` or
`--output-directory`.
These options have also been added to gdbus-codegen's documentation.
https://bugzilla.gnome.org/show_bug.cgi?id=791015
The `outdir` and `docbook` parameters are passed to the
`DocbookCodeGenerator` constructor, but these parameters are only
used at docbook generation, which is optional.
The parameters have been removed from the class creation and added
to the `generate` method, where they are actually being used.
https://bugzilla.gnome.org/show_bug.cgi?id=791015
The class that generated both C header and code has been split into
two classes. These clases are now specialized on creating the header
or the body code.
All parameters that do not belong to each class have also been
deleted, so only the necessary parameters still remain. These also
includes the header and code file descriptors, leaving only the
corresponding file descriptor necessary for each class.
https://bugzilla.gnome.org/show_bug.cgi?id=791015
The generation of the C header and code preambles have been split
in order to be able to generate both files separately in the future.
The functions for generating preambles and postambles have also been
renamed following the function names used in the glib-genmarshal
rewrite, so that they stay consistent.
https://bugzilla.gnome.org/show_bug.cgi?id=791015
The #pragma once is widely supported preprocessor directive that can
be used instead of include guards.
This adds support for using optionally this directive instead of
include guards.
https://bugzilla.gnome.org/show_bug.cgi?id=791015
The optparse module is deprecated since version 2.7 and the
development continues with the argparse.
The code has been moved from optparse to argparse when parsing
command-line options. This has also led to the deprecation of the
`--xml-files`, and positional arguments should be used instead.
https://bugzilla.gnome.org/show_bug.cgi?id=791015
`glib-genmarshal` and `glib-mkenums` use a `Color` class which
implements a number of print_* methods to print colored messages
to the standard error output.
In order to be consistent with those programs' output,
`gdbus-codegen` has also started using that same class and methods.
https://bugzilla.gnome.org/show_bug.cgi?id=791015
On i386, we were seeing that this calculation was producing an incorrect
result, probably because usec was being stored in an 80-bit register
before being written back into a 64-bit float in memory. If we mark the
variables as volatile, they are not stored in registers and we avoid
this bug.
gtk-doc doesn’t support them any more since it was ported to Markdown,
so they end up appearing in the generated documentation, which isn’t
great.
Mostly, they were used to split up things invisibly, which we can do in
other ways.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Reviewed-by: nobody
Try and make it a bit more obvious that g_file_query_exists() is
generally A Bad Idea.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Reviewed-by: nobody
gtk-doc was mis-parsing the combination of ` and :: and truncating some
of the documentation. Avoid that by using the D-Bus style of separating
interface and signal names using a dot.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Reviewed-by: nobody
There is no requirement that groups is NULL terminated, so we should check
that the bounds are within the specified length before checking for a
NULL terminating value.
https://bugzilla.gnome.org/show_bug.cgi?id=792351
Because the argument being called "available" and the property being
called "network-available" is confusing.
Also remove the details of what that value means, as it's already
described in the property, and duplicating the explanation makes it look
like it might have a different meaning.
https://bugzilla.gnome.org/show_bug.cgi?id=792370
The g_dbus_connection_call() documentation doesn’t make it clear that
the reply type is always a tuple.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Reviewed-by: nobody
The license string which is embedded in the C header and body
preambles has been moved to a global variable. This way it can be
reused in both sections.
https://bugzilla.gnome.org/show_bug.cgi?id=791015
I originally planned to introduce a new property and functions to
replace these, with the same behavior but less-confusing names. But that
might not be the best approach in the long run. Instead, let's just
deprecate them without replacement.
TLS 1.2 intolerance is no longer a thing in the wild, and no known
GTlsBackend supports TLS 1.3 yet. But you might need to use this
property in the future, even though it's deprecated, if your
GTlsBackend has added support for TLS 1.3 and you need to talk to a
server that is TLS 1.3 intolerant.
Independently of all that, these APIs simply no longer do what their
names suggest, so deprecation is sensible regardless.
https://bugzilla.gnome.org/show_bug.cgi?id=792217
The property documentation correctly indicates how this code works
nowadays, but the function documentation is obsolete and misleading.
Update it.
https://bugzilla.gnome.org/show_bug.cgi?id=792217
Custom desktop file fields may be translated, but there is currently
no non-hacky way to look up the localized value; fill get gap with
a small wrapper around g_key_file_get_locale_string().
https://bugzilla.gnome.org/show_bug.cgi?id=779413
The source object for this asynchronous operation is the GXdpOpenURI,
not a GDBusConnection. This was causing crashes in method calls on the
connection, unsurprisingly.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=791720
This was introduced in bug #742997, but not added to the Makefile.am, so
it’s missing from tarballs.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Reviewed-by: nobody
https://bugzilla.gnome.org/show_bug.cgi?id=792322
Hopefully discouraging people from overriding that and building with it
enabled.
Pro-tip: GLib will break.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=791622
GLib makes various assumptions about aliasing throughout its codebase,
and compiling with -fstrict-aliasing has been demonstrated to cause
problems (for example, bug #791622). Explicitly disable strict aliasing
as a result.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
gpointer* cannot be aliased with arbitrary types. In order to fix
-Wstrict-aliasing=2 warnings with the g_clear_pointer() macro, we need
to cast through char*, which is allowed to alias with anything.
Even if we don’t make GLib strict-aliasing safe, it’s important to
ensure this macro is safe, since it could be used from projects which do
compile with -fstrict-aliasing.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=791622
Fix various strict aliasing problems caused by casting between (struct
sockaddr *) and (struct sockaddr_storage *): the correct code here is to
keep the two in a union.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=791622
When using g_key_file_get_locale_string() or get_locale_string_list(),
the GKeyFile must have been loaded with G_KEY_FILE_KEEP_TRANSLATIONS if
the lookup locale differs from the one which was current when the key
file was loaded.
Document that.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=792324
As 'auto' dependency checking has been declared undesirable,
skip checking of optional dependencies where the option
defaults to true, but where the option doesn't make sense for
the operating system we're building for. Example: selinux only
makes sense on Linux, people compiling on Windows or macOS
shouldn't have to specify -Dselinux=false to get glib to build.
https://bugzilla.gnome.org/show_bug.cgi?id=792129
Commit 281e3010 narrowed the race between GCancellable::cancelled and
GCancellableSource's finalize(), but did not prevent it: there was
nothing to stop cancellation from occurring after the refcount drops
to 0, but before g_source_unref_internal() bumps it back up to 1 to
run finalize().
GCancellable cannot be expected to detect that situation, because the
only way it has to detect last-unref is finalize(), but in that
situation finalize() hasn't happened yet.
Instead of detecting last-unref, relax the precondition a little
to make it detect finalization: priv is only poisoned (set to NULL)
after the finalize() function has been called, so we can assume that
GCancellable has already seen finalize() by then.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=791754
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=884654
If we don't take the lock, then we don't have the necessary
"happens before" relationships to avoid this situation:
* source->priv->ready_time was equal to ready_time until recently
* another thread has set source->priv->ready_time to a different value
* that write hasn't become visible to this thread yet
* result: we should reset the ready_time, but we don't
Signed-off-by: Simon McVittie <smcv@collabora.com>
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=791754
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=884654
