off64_t doesn’t exist in any standard (definitely not C99), and so
goffset is actually closer to off_t in 64-bit mode.
However, goffset is always defined as gint64, so make that clear.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=792856
Check for g_hostname_to_ascii() failure, rather than crashing when
checking whether an invalid hostname should go through the proxy.
The HTTP library should report the error about the invalid hostname
once we actually try to connect to it.
https://bugzilla.gnome.org/show_bug.cgi?id=772989
If the underlying transport is D/TLS the same data and data length
is required to be sent on the next iteration when a WOULD_BLOCK
happens. This is due to the fact that gnutls or openssl keep
an internal state for the data.
https://bugzilla.gnome.org/show_bug.cgi?id=792862
See the discussion in the bug report: with proxy support enabled, a
proxy resolver is created. Doing that will load all the GIO modules, and
typically at least one of them will try to use GDBus during
initialisation, which will cause a deadlock.
Using a TCP address with GDBusAddress is still supported, but accessing
it over a proxy is not.
Document this.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=792499
Recent changes has extended the functionality of `gdbus-codegen`
by implementing new options.
This patch extends the documentation including the behaviour of
the new options along the old ones.
(Wording tweaked by Philip Withnall before pushing.)
https://bugzilla.gnome.org/show_bug.cgi?id=791015
In cases where gdbus-codegen is used only for docbook generation,
the execution stops with the following error message:
`Using --header or --body requires --output`
This is because it was assumed that, in addition to the docbook
generation, the header or source code were always generated.
This patch fixes this, and the header or source code generation
is not mandatory, so the docbook can be generated separately.
https://bugzilla.gnome.org/show_bug.cgi?id=791015
Skip accumulated events from file monitor which we are not able to handle
in a real time instead of emitting mounts_changed signal several times.
This should behave equally to GIOChannel based monitoring. See Bug 792235.
https://bugzilla.gnome.org/show_bug.cgi?id=793006
The chmod of all the scripts we generate from a template via configure
is necessary because configure will not preserve the bits of the
template when generating a new file.
There's no explanation for it, and you have to hunt it down the commit
history. Since Meson does the right thing, we added the executable bit
on the templates, but we cannot remove the AC_CONFIG_COMMANDS macro from
the Autotools build without breaking it. Let's document this, to avoid
nasty surprises.
This adds two new tests for g_bytes_new_from_bytes().
One test ensures that when creating a new GBytes that is a slice of
the entire base bytes, we just return the base bytes with it's reference
count incremented by one.
The other test ensures that when performing sub-slices of GBytes, for
which the parent GBytes also references a GBytes, that we skip the
intermediate GBytes and reference the base GBytes. Additional testing
of the internal state of the GBytes structure is performed to prove
the correctness of the implementation.
https://bugzilla.gnome.org/show_bug.cgi?id=792780
When referencing a GBytes that is already a slice of another GBytes, we
can avoid referencing the intermediate GBytes and instead reference the
root bytes.
Doing so helps avoid keeping N GBytes instances alive when the
intermediates would have otherwise been finalized.
https://bugzilla.gnome.org/show_bug.cgi?id=792780
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
