These might help catch the problem in #2119 earlier on, and provide more
information about its root cause.
They should not affect behaviour in normal application usage.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2119
This is technically an API break, as the following assignment may now
raise warnings in user code:
```
gchar *filename = g_osx_app_info_get_filename (app_info);
```
However, from code search it seems like the number of users of that
function is zero.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This command will try to execute a desktop file, before that
it will load the input as a keyfile for checking its existence
and its validity (as a keyfile).
File arguments are allowed after the desktop file.
Closes#54
Signed-off-by: Frederic Martinsons <frederic.martinsons@sigfox.com>
When this is called on the source or target, the weak notify of the
corresponding object is called without the GWeakRef being cleared.
See https://gitlab.gnome.org/GNOME/glib/-/issues/2266 for that issue.
This means that a strong reference to these zombie objects can be
retrieved from the GWeakRefs and the previous assumption that this can't
happen was wrong. Remove the assertion for that accordingly and handle
this case.
Specifically, all signal handlers and weak notifies of the object are
already gone and must not be disconnected/removed a second time, or
otherwise memory corruption would be caused. Instead just set the
GWeakRef to NULL and handle it otherwise as if the GWeakRef didn't give
a strong reference to begin with.
Fixes https://gitlab.gnome.org/GNOME/glib/-/issues/2265
This especially has the effect that any GWeakRefs to the object will not
necessarily be set to NULL yet if called as part of
g_object_run_dispose() and not as part of g_object_unref().
This doesn’t change the behaviour of the code, but should squash some
compiler/static analysis warnings about ‘are you sure you got the
precedence right here?’.
Coverity CID: #1159470
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Static analysis of the call to `g_dir_new_from_dirp()` is tricky,
because the call is across library boundaries and indirected through a
vfunc map because it’s private to libglib.
Help the static analyser by adding an assertion about the input and
output values for `g_dir_new_from_dirp()`.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
There’s no explicit guarantee that any of these functions are safe to
use on untrusted data, but it does no harm to test them.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
It search for attribute trash::orig-path and move the input file to it.
Possibly recreating the directory of orignal path and/or overwritting
the destination.
Closes#2098
Signed-off-by: Frederic Martinsons <frederic.martinsons@sigfox.com>
gobject/tests/value.c: In function ‘test_valuearray_basic’:
gobject/tests/value.c:253:17: error: comparison of integer expressions of different signedness: ‘gint’ {aka ‘int’} and ‘guint’ {aka ‘unsigned int’}
253 | for (i = 0; i < a->n_values - 1; i++)
| ^
gobject/tests/value.c:257:17: error: comparison of integer expressions of different signedness: ‘gint’ {aka ‘int’} and ‘guint’ {aka ‘unsigned int’}
257 | for (i = 0; i < a->n_values; i++)
| ^
The `nameprep()` function in `ghostutils.c` is quite complex, and does a
lot of allocations. This means it can take a long time on long hostnames
(on the order of 10KB long). Hostnames should never be that long,
though, so impose some loose length limits.
oss-fuzz#27371
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
There were a couple of places where the return value wasn’t checked, and
hence failure could not be noticed.
Coverity CIDs: #1159435, #1159426
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
It’s possible that GLib will eventually be compiled against a version of
libc which supports `close_range()` (hence `HAVE_CLOSE_RANGE` will be
defined), but then run against an older kernel which doesn’t support it.
In this case, we want to fall back to `fdwalk()`, which should work on
such systems.
This is what cpython does: 3529718925/Python/fileutils.c (L2227)
Spotted by Allison Karlitskaya in !1688.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
The function declaration we use changed a bit since then.
In particular, some arguments became const. See following commit.
libselinux-2.2 was released on 20131030, and is widely available in
all major stable distributions.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
From:
9eb9c93275
"we found that the const security_context_t declarations in libselinux
are incorrect; const char * was intended, but const security_context_t
translates to char * const and triggers warnings on passing const char *
from the caller. Easiest fix is to replace them all with const char *."
And later marked deprecated in commit:
7a124ca275
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
They extend the behavior of, respectively, -p and -s options of the
glib test framework
Currently test suite are only run for one level under -p path, for
example, testfilemonitor -p /monitor would execute the following tests:
/monitor/atomic-replace
/monitor/file-changes
/monitor/dir-monitor
/monitor/dir-not-existent
/monitor/cross-dir-moves
With the --run-prefix the sub-test suite file will be executed:
/monitor/atomic-replace
/monitor/file-changes
/monitor/dir-monitor
/monitor/dir-not-existent
/monitor/cross-dir-moves
/monitor/file/hard-links
The --skip-prefix and run-prefix seems symmetrical, but there is a
difference with skip towards run:
--skip-prefix will use a prefix while --run-prefix only work for a valid test path.
For example and for the following test family:
/monitor/atomic-replace
/monitor/file-changes
/monitor/dir-monitor
/monitor/dir-not-existent
/monitor/cross-dir-moves
/monitor/file/hard-links
while --run-prefix /mon will not execute anything, --skip-prefix /mon
will skip all of these tests.
See #2238 which references this change.
- Add a test for parsing FILE scheme from uri
It had taken from GST test_protocol_case
- Add a split uri test with encoded spaces in its path
It had taken from GST test_uri_get_location
- Add tests for g_uri_is_valid
It had taken from GST test_uri_misc
Note that the 4 followings uri failed under gst_uri_is_valid but not
under g_uri_is_valid
B:\\foo.txt
B:/foo.txt
B://foo.txt
B:foo.txt
- Add tests for g_uri_split
It had taken from GST test_url_parsing
- Add tests for test_uri_normalize and test_uri_parsing_relative
The test URI had been taken from GST test_url_normalization
- Add tests for test_uri_iter_params
It had taken from GST test_url_unescape_equals_in_http_query
Closes#2150
Signed-off-by: Frederic Martinsons <frederic.martinsons@sigfox.com>
This was inconsistently handled before and only explicit unbinding or
finalizing the binding would've previously released the transform
function. If the source/target were finalized while more strong
references to the binding still existed then the transform function
would stay alive and only the binding itself would be deactivated.
Unbinding can happen from one thread while a property notification is
being handled concurrently in another one.
To solve this, introduce a reference counter for the transform function
that ensures that it always stays valid while in use and protect access
to the one stored inside the binding with the unbind mutex.
It's possible for g_binding_unbind() to be called at the same time as
one (or both) of source and target are being finalized. The resulting
unbinding needs to be protected with a mutex to ensure that it only
happens exactly once.
As the first reference is owned by both weak notifies and the caller of
g_object_bind_property(), additional indirections are needed to ensure that
unreffing the first reference after creation still unbinds the binding
as before. This seems to be a common code pattern and how this was
intended to be used, but is only safe in single-threaded contexts as it
relies on both the source and target object to be still alive.
Add a lot of comments to the code about all these dependencies and a
couple of assertions to ensure they hold valid.
Also document that inconsistent reference ownership handling of
g_binding_unbind() that makes it unfit for automatically generated
language bindings.
