String inputs to convenience conversion functions g_locale_from_utf8(),
g_filename_from_utf8(), and g_filename_to_utf8(), are annotated for the
bindings as NUL-terminated strings of (type utf8) or (type filename).
There is also a len parameter that allows converting part of the string,
but it is exposed to the bindings as a value independent from the string
buffer. Absent any more sophisticated ways to annotate, the way to
provide a safeguard against len argument values longer than the
string length is to check that no nul is encountered within the first
len bytes of the string. strdup_len() includes this check as part of
UTF-8 validation, but g_convert() permits embedded nuls.
For g_filename_from_utf8(), also check the output to prevent embedded NUL
bytes. It's not safe to allow embedded NULs in a string that is going
to be used as (type filename), and no known bytestring encoding for
file names allows them.
https://bugzilla.gnome.org/show_bug.cgi?id=792516
The character encoding conversion utility functions g_locale_to_utf8()
and g_filename_to_utf8() had inconsistent behavior on producing strings
with inner NUL bytes: in the all-UTF-8 strdup path, the input string
validation prohibits embedded NULs, while g_convert(), using iconv(),
can produce UTF-8 output with NUL bytes inside the output buffer.
This, while valid UTF-8 per the Unicode standard, is not valid for
the nul-terminated (type utf8) return value format that the *_to_utf8()
functions are annotated with (as per discussion in bug 756128).
Check the output of g_convert() for embedded NUL bytes, and if any
are found, set the newly introduced error
G_CONVERT_ERROR_EMBEDDED_NUL.
Also document the error set by g_{locale,filename}_{from,to}_utf8()
when the input string contains nul bytes.
https://bugzilla.gnome.org/show_bug.cgi?id=792516
In the strdup_len() path, no need to do what g_utf8_validate()
already does: locate the string-terminating nul byte.
Also in strdup_len(), make the out parameter bytes_read receive the length
of the valid (meaning also nul-free) part of the input string, as the
documentation on g_{locale,filename}_{from,to}_utf8() says it does.
https://bugzilla.gnome.org/show_bug.cgi?id=792516
This reverts the following commits (but keeps the other recent changes
to gmain.c):
• e4ee3079c Do not wake up main loop if change is from same thread
• 208702404 main: Create a helper function for "owner wakeup" optimization
• 0c0469b56 gmain: Signal wakeups if context has never been acquired as well
• 9ba95e25b gmain: only signal GWakeup right before or during a blocking poll
Some combination of them is causing problems with LibreOffice and/or
WebKit, and the safest thing to do at the moment is revert them all
until we work out what’s going on. The previous revert (4976e8109) was
not sufficient (it fixed WebKit, but re-broken LibreOffice).
By reverting, we gain some spurious wakeups, but avoid dropping
necessary wakeups, which is presumably what’s causing problems in the
other modules.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=761102
This makes it more consistent with the other win32 objects in GIO. This
commit just renames the files; a follow-up commit will rename the
GObject.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=685442
Added a Windows backend to GNetworkMonitor, using NotifyRouteChange2()
(available on Vista and later). It marshals the route change callbacks
to the thread-specific default main context the GNetworkMonitor was
constructed in.
https://bugzilla.gnome.org/show_bug.cgi?id=685442
It was documented at strange places: in g_sequence_search*() and
g_sequence_lookup*(), but how to insert and sort data is not done by
those functions.
So instead, add the information to the class description (since it
involves several functions), and add also the information in
g_sequence_insert_sorted() and g_sequence_insert_sorted_iter() as a kind
of warning when using those functions.
Note that before this commit, it was not explained *why* it is better to
call g_sequence_sort() after doing a lot of unsorted insertions. Now it
is documented as "more efficient" (I think it's the only reason that
makes sense, otherwise why was it documented?).
https://bugzilla.gnome.org/show_bug.cgi?id=792455
The tool was ported to Python, but we should not mention the programming
language used, in case we port it to some other language in the distant
future.
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
