Check for over- and underflow when manipulating positions.
This makes the sequence
g_list_model_get_item (store, 0);
g_list_model_get_item (store, -1u);
return NULL for the second call, as it should.
Closes: #1639
Calling
g_list_model_get_item (store, 0);
g_list_model_get_item (store, -1u);
does not return NULL for the second call, as it should.
This was showing up in GTK+ list model tests.
Since commit 290bb0dd, where various members of GTask were converted to
a bitfield, some of the getters:
• g_task_get_check_cancellable()
• g_task_get_return_on_cancel()
• g_task_get_completed()
have been returning truthy ints (zero or an arbitrary non-zero integer)
as boolean values, rather than the canonical boolean ints of 1 and 0.
This broke the `yield` statement in Vala, whose generated C code
compares `g_task_get_completed (…) != TRUE`. i.e. Whether the
`completed` field has a value not equal to 1.
Fix this by explicitly converting truthy ints to canonical boolean ints
in all getters.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/1636
This is a new polling method allowing to poll more than 64 handles
based on the glib one.
When we reach the limit of 64 we create a thread and we poll
on that thread for a batch of handles this way we overcome the limit.
https://gitlab.gnome.org/GNOME/glib/issues/1071
And mention why it’s not a GInterfaceInitFunc as people who have read
the GObject docs cover-to-cover might expect.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
According to msdn documentation last backslash(es) of quoted argument
in a win32 cmdline need to be escaped, since they are
directly preceding quote in the resulting string:
https://docs.microsoft.com/en-us/cpp/c-language/parsing-c-command-line-arguments
Glib <=2.58.0 passed children arguments like C:\Program Files\
without escaping last backslash(es).
So it had been passed as "C:\Program Files\"
windows command line parsing treated this as escaped quote,
and later text was treated as argument continuation instead of separate
arguments.
Existing implementation wasn't easily adoptable to fix this problem,
so escaping logic was rewritten.
Since the resulting length need to be increased due to extra escaping
it was rewritten too. Now the calculated length assumes that all
escapable chars would be escaped in a resulting string,
so the length may be a bit bigger than actually needed,
since backslashes not preceding quotes are not escaped.
This fixes the glib/tests/spawn-singlethread.c test
(which introduced testing for special chars to make this problem
testable).
The problem itself was found during investigations about fixing
related https://gitlab.gnome.org/GNOME/glib/issues/1566
The logic is duplicated in protect_argv_string() and protect_wargv() funcs.
However there is no single obvious way to get rid of duplication -
https://gitlab.gnome.org/GNOME/glib/merge_requests/419#note_371483
So by now adding a note referencing protect_wargv from protect_argv_string,
the other direction is already referenced.
This fixes test that were added in previous commit:
checking for empty stderr failed with coverage enabled, since
coverage warnings printed from gspawn-win32-helper process were treated
as child output. This is fixed by removing redirection after child
finishes execution.
The dup_noninherited renamed to reopen_noninherited,
since it actually always closes passed file descriptor.
Problem was just a typo - wrong variable was checked before enabling
stderr redirection.
This fixes error-only redirection spawn-test added in previous commit.
Behavior while redirecting only stdout should be unaffected,
since old code tried to redirect stderr to -1 in such case,
which silently failed I think.
The spawn_test is enabled on win32 meson build, both msys and msvc.
Some modifications to make it useful for auto-testing on win32:
- use own argv0 to find helper win32-specific subprogram
- helper subprogram and conditions changed, so testing is fully
automated instead of manually checking contents of some MessageBoxes
Redirection test checks "sort" output for locale-independent string
instead of relying on "netstat" locale-dependent string.
Also with "sort" it become usable on unix, so enabled there too.
Currently this fails on win32 with coverage since
some coverage-realted error output from gpawn-win32-helper
is unexpectedly treated as executed subprocess output.
Added test checking "sort" with error-only redirection. This also fails
on win32 by now, due to a typo in gspawn-win32.c (checks for stdout
redirection instead of stderr)
The existing singlethread g_spawn_sync test is modified and now tests
that special characters in arguments are correctly passed to child.
The test is added before spawn escaping fixing on win32
and covers the case currently broken on win32:
'trailing \ in argument containing space'.
It has different semantics from _Alignof and our G_STRUCT_OFFSET
fallback. See the comments in the diff for details.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/1055
Note that it's not reported with gcc. It's only reported with g++.
C++ code to reproduce this warning:
#include <glib-object.h>
G_BEGIN_DECLS
#define GARROW_TYPE_FILE (garrow_file_get_type())
G_DECLARE_INTERFACE(GArrowFile,
garrow_file,
GARROW,
FILE,
GObject)
struct _GArrowFileInterface {
GTypeInterface g_iface;
};
G_DEFINE_INTERFACE(GArrowFile,
garrow_file,
G_TYPE_OBJECT)
static void
garrow_file_default_init(GArrowFileInterface *iface)
{
}
G_END_DECLS
Build command line:
% g++ -Wall -shared -o liba.so a.cpp $(pkg-config --cflags --libs gobject-2.0)
Message:
In file included from /tmp/local.glib/include/glib-2.0/gobject/gobject.h:24,
from /tmp/local.glib/include/glib-2.0/gobject/gbinding.h:29,
from /tmp/local.glib/include/glib-2.0/glib-object.h:23,
from a.cpp:1:
a.cpp: In function 'GType garrow_file_get_type()':
/tmp/local.glib/include/glib-2.0/gobject/gtype.h:219:50: warning: '<<' in boolean context, did you mean '<' ? [-Wint-in-bool-context]
#define G_TYPE_MAKE_FUNDAMENTAL(x) ((GType) ((x) << G_TYPE_FUNDAMENTAL_SHIFT))
~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~
/tmp/local.glib/include/glib-2.0/gobject/gtype.h:2026:11: note: in definition of macro '_G_DEFINE_INTERFACE_EXTENDED_BEGIN'
if (TYPE_PREREQ) \
^~~~~~~~~~~
/tmp/local.glib/include/glib-2.0/gobject/gtype.h:1758:47: note: in expansion of macro 'G_DEFINE_INTERFACE_WITH_CODE'
#define G_DEFINE_INTERFACE(TN, t_n, T_P) G_DEFINE_INTERFACE_WITH_CODE(TN, t_n, T_P, ;)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~
a.cpp:16:1: note: in expansion of macro 'G_DEFINE_INTERFACE'
G_DEFINE_INTERFACE(GArrowFile,
^~~~~~~~~~~~~~~~~~
/tmp/local.glib/include/glib-2.0/gobject/gtype.h:178:25: note: in expansion of macro 'G_TYPE_MAKE_FUNDAMENTAL'
#define G_TYPE_OBJECT G_TYPE_MAKE_FUNDAMENTAL (20)
^~~~~~~~~~~~~~~~~~~~~~~
a.cpp:18:20: note: in expansion of macro 'G_TYPE_OBJECT'
G_TYPE_OBJECT)
^~~~~~~~~~~~~
Names are a message bus feature, so it does not make sense to connect
to NameOwnerChanged when the underlying connection is not a message
bus.
Moreover, g_dbus_connection_signal_subscribe() will also enforce that
condition. Adding this extra check here is helpful to avoid a critical
warning when using GDBusProxy with peer-to-peer connections.
https://gitlab.gnome.org/GNOME/glib/issues/1620
Right now this can only be set at construction but not read back.
That seems unnecessarily restrictive, and we'll need to read these
flags from outside of gdbusconnection.c in the next commit, so let's
just make it public.
https://gitlab.gnome.org/GNOME/glib/issues/1620
Add option to not encode resource data into the C source file
in order to embed the data using `ld -b binary`. This improves compilation
times, but can only be done on Linux or other platforms with a
supporting linker.
(Rebased by Philip Withnall, fixing minor rebase conflicts.)
Fixes#1489
This reverts commit 52bab0254a.
It silently conflicted with another commit,
90ca3b4dd0, which was merged later than
it. I’ve kept commit 90ca3b because it also frees the GError; 52bab
doesn’t.
This is my failure to rebase and test old branches before merging them,
instead of assuming that the lack of automatically detected merge
conflicts actually means there are no merge conflicts.
