- Remove periods from parameter descriptions
- Start parameter descriptions lower case
- Shorten nullable parameter descriptions
- Start parameter descriptions with a/the
- Start boolean action descriptions with if
- Start return value description with "The"
- Adjust boolean return value descriptions
- Skip type in parameter description
Deviate from the GNOME Developer Documentation
guidelines only in special cases to deliver more information:
https://developer.gnome.org/documentation/guidelines/devel-docs.html#callable-symbols
He’s made a lot of detailed contributions recently, and has a good
understanding of large parts of GObject.
I‘ve asked him (by private email) if he’d agree to be added to the
co-maintainers list, and he said he’d be pleased to.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Try to avoid casting variables to potentially smaller types to fit
defined probes. This can truncate values and lead to wrong results.
Also make sure that signedness matches.
Since GType can be even 128 bit on CHERI architecture, cast all these
various types used based on platform to uintmax_t which SystemTap
properly processes.
It’s not particularly clear why both these exist and why you need to use
both of them when creating a `GValue` — but you do.
Try and clarify things in the documentation.
In particular, replace use of the term ‘uninitialised’ (referring to a
`GValue` which has been set to `G_VALUE_INIT` but not yet had
`g_value_init()` called on it) with ‘zero-filled (cleared)’ instead.
‘uninitialised’ doesn’t make sense to describe a variable which, in C
terms, has just been initialised by assigning `G_VALUE_INIT` to it.
‘cleared’ is a bit less overloaded as a term.
Add some code examples to hopefully make things clearer too.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Development versions of glib like 2.85.2 produce library files with
names like "libglib-2.0.so.0.8502.0" whereas stable version names
are like "libglib-2.0.so.0.8400.2".
The produced stp files for SystemTap work for stable versions but not
for development versions.
Fix this by passing the correct variables into LT_CURRENT and
LT_REVISION.
Based on my reading of the docs, g_spawn_async_with_pipes_and_fds()
seems to have a much more comprehensive explanation of itself than
g_spawn_async_with_pipes(). As such, it makes sense to me to refer to it
rather than the latter when suggesting where to go for further reading.
Signed-off-by: Stefan Hansson <newbyte@postmarketos.org>
If g_ascii_strtoll does not use strtoll_l, the result of
g_parse_long_long could be G_MININT64 with gboolean negative set.
In such a case, returning `- (gint64) result` would lead to an undefined
behavior because -G_MININT64 would lead to an implicit integer overflow.
Realistically though, this still leads to G_MININT64. Fixes test failure
if compiled with ubsan on a platform without strtoll_l.
Some GByteArray functions already pass through the return values of
called GArray functions. Do so for all functions so callers might
react to errors and for consistency.
The Meson test harness handles that for us.
With a custom timeout, meson test -t is not useful (which is
surprising for users) and interactive debugging sessions may
terminate unexepectedly.
Make sure that arguments are not null. While internal functions are
properly protected, the code execution continues and eventually leads
to a NULL pointer dereference.
