Beef up the singleton testcase to reproduce a
freeze count underflow when setting properties
at construction time, with a custom constructor.
Helps: #2666
These are deprecated, but it’s easy enough to test them anyway. This
bumps up code coverage a bit and hopefully ensures we don’t accidentally
regress on them in future.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
At the moment these tests basically just ensure that the program’s
compiled properly and doesn’t crash on startup. They don’t check
functionality very deeply.
But they’re a start.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This has been documented in `man gobject-query` for a long time, but
seemingly never implemented.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This makes the output a lot nicer to read:
```
│
├void
│
├GInterface
│ │
│ └GTypePlugin
│
├gchar
⋮
```
rather than
```
|
`void
|
`GInterface
|
`GTypePlugin
|
`gchar
⋮
```
It includes a change to correctly use vertical tees at the top level by
correctly setting the sibling node rather than always setting it to
zero.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This doesn’t change the tests’ behaviour, but moves them to a slightly
more logical location.
They are still not installed or run by default.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1434
Install the properties with a mixture of
g_object_class_install_properties and
g_object_class_install_properties, and verify
that finding them still works, regardless of
whether we use string literals or not.
When the param specs are provided as an array
with g_object_class_install_properties, keep
a copy of that array around and use it for
looking up properties without the param spec
pool.
Note that this is an opportunistic optimization -
currently, it only works for properties of the
class itself, not for parent classes, and it
only works if the property names are identical
string literals (we're at the mercy of the linker
for that).
If we don't get lucky, we fall back to using
the pspec pool as usual.
Atomic APIs provide a way to exchange values only if we compare a value
that is equal to the old value, but not to just exchange the value
returning the old one.
However, compilers provide such built-in functions, so we can use them
to expose such functionality to GLib.
The only drawback is that when using an old version of gcc not providing
atomic APIs to swap values, we need to re-implement it with an
implementation that may not be fully atomic, but that is safe enough.
However this codepath should really not be used currently as gcc
introduced __atomic_exchange_n() at version 4.7.4, so 8 years ago.
`ptr_array_null_terminate()` only `NULL`-terminates the array if its
`null_terminated` flag is set; otherwise it’s a no-op.
Rename the function to `ptr_array_maybe_null_terminate()` to make that a
bit clearer, and make it consistent with `g_ptr_array_maybe_expand()`.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This may fix Coverity assuming that pspecs are leaked, which is causing
tens and tens of false positives in the latest Coverity reports for
GLib.
Ensure that the pspecs are sunk (if floating) even if adding them to the
class fails (due to validation failure or an identically named property
already existing).
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Dynamically, all the right elements of `ps` are initialised before they
are used. However, scan-build doesn’t think so. It (probably) thinks
that `number_of_blocks` could change value between the different loops
over `ps`.
Try and avoid that by marking `number_of_blocks` (and related variables)
as `const`.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
It seems that scan-build assumes `n_threads > 0`, but doesn’t assume a
tighter condition than that, and hence assumes that the two loops to
initialise and join the threads have different numbers of iterations.
That’s obviously not the case.
Try and help scan-build out here by marking `n_threads` as `const`. I
don’t know if this will work, but it’s correct regardless.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
scan-build can’t link the types used in `g_variant_builder_init()` with
the (same) types used in `g_variant_builder_end()`, so ends up assuming
that the children have not been initialised.
At runtime, this is prevented by the precondition checks on
`GVSB()->offset` in `g_variant_builder_end()`. scan-build doesn’t notice
that though.
Avoid a scan-build warning by zero-initialising the children array when
running static analysis. Doing this unconditionally would be an
unnecessary performance hit.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
