They do not start with the #!/usr/bin/python that would be necessary
to make them run with Python rather than a shell, and they would
not be useful to run anyway: they are libraries to be imported,
not scripts to be run.
Signed-off-by: Simon McVittie <smcv@debian.org>
g_utf8_make_valid was turned into a public API this cycle. However
now that it is public we should make the API more generic, allowing
the caller to specify the length. This is especially useful if
the function is called with a string that has \0 in the middle
or for chunks of a strings that are not nul terminated.
This is also consistent with most of the other utf8 utils.
Callers inside glib are updated to the new signature.
https://bugzilla.gnome.org/show_bug.cgi?id=779456
In my previous attempt to improve colored console output on Windows, we
called GetFileInformationByHandleEx() directly if we target Vista or
later, but the check macro for doing so via LoadLibrary() had a typo. Fix
this by correcting the check macro.
Pointed out by Ignacio Casal Quinteiro.
g_settings_schema_source_get_default() is (transfer none), not (transfer
full).
Spotted by Marvin Schmidt.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=779265
On the warning/critical error handling paths for g_settings_set(), the
GVariant value was not ref-sunk, and the schema key was leaked. This
won’t affect code in production (unless it’s seriously buggy), but
eliminates some leaks from the error testing paths in the GSettings
tests.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=779265
Spotted while running `make check` under Valgrind. While it’s not
necessary to fix memory leaks in glib-compile-schemas (since it’s a
utility which runs briefly then exits), fixing them makes more
legitimate leaks in the Valgrind output more obvious, and means we can
be sure there aren’t leaks in the underlying GLib/GIO code which
glib-compile-schemas is calling.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=779265
When unregistered extension point (i.e. NULL pointer) is passed
to `g_io_extension_point_get_extensions`, it causes a segfault.
This commit adds an assertion, to prevent this.
https://bugzilla.gnome.org/show_bug.cgi?id=779183
Happens when the waiting-for-auth state is re-entered:
SERVER_STATE_WAITING_FOR_AUTH
|
v
G_DBUS_AUTH_MECHANISM_STATE_REJECTED
|
v
SERVER_STATE_WAITING_FOR_AUTH
Causing the previous `mech` pointer to get overwritten.
https://bugzilla.gnome.org/show_bug.cgi?id=778991
It has the same block size as SHA-512, so it just needs a new case in
the switch, some documentation updates, and the test vectors from RFC
4868.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=771997
We're first getting the notification by its notify_id, but activating
the action afterwards could redraw it, leading to a dangling pointer.
Fix this by simply searching the list of active notifications again
after activating the action.
As in the version in of this NMake Makefile module in G-I, support
CFG == Release|Debug, which is what is used in the Visual Studio
projects, so that:
-This file will be in sync with the one in G-I
-Other projects that make use of this can integrate this NMake Makefile
module in their Visual Studio project files.
Update this common NMake Makefile module so projects using this (such as
for introspection builds or projects supporting MSVC builds using NMake)
can make use of Visual Studio 2017.
This adds support for Visual Studio 2017 by updating the autotools files for
copying and updating the Visual Studio 2010 project files.
Since the toolset version of Visual Studio 2017 is no longer in the form
of $(MSVC_VER_SHORT)0, we need to specify the full number, but this is a
rather simple change we have here. Note that Visual Studio 2017's CRT
aims to be compatible with the 2015's CRT, so it should be possible to
use 2017-compiled code with the 2015-compiled ones.
GNOME Builder's code was assuming that setting the launcher's
environ to NULL makes the subprocess have an empty environment, but in
fact the parent process's variables are still inherited because execv is
used instead of execve when envp is NULL. This commit clarifies the
documentation to make the behavior clear.
https://bugzilla.gnome.org/show_bug.cgi?id=778422
