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>
The implementation didn’t match the documentation. The implementation
has the right behaviour (wrt not allowing embedded nuls, validating
UTF-8, and returning a default value if an invalid string is detected),
so keep that and fix the documentation to match.
The [`GVariant`
specification](https://people.gnome.org/~desrt/gvariant-serialisation.pdf)
is incorrect on this point, and the implementation of GLib was
purposefully changed after the specification was published (but before
`GVariant` became API-stable in GLib). The behaviour in GLib
(specifically concerning all strings being in UTF-8) is consistent with
D-Bus.
Spotted by William Manley.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This was mostly machine generated with the following command:
```
codespell \
--builtin clear,rare,usage \
--skip './po/*' --skip './.git/*' --skip './NEWS*' \
--write-changes .
```
using the latest git version of `codespell` as per [these
instructions](https://github.com/codespell-project/codespell#user-content-updating).
Then I manually checked each change using `git add -p`, made a few
manual fixups and dropped a load of incorrect changes.
There are still some outdated or loaded terms used in GLib, mostly to do
with git branch terminology. They will need to be changed later as part
of a wider migration of git terminology.
If I’ve missed anything, please file an issue!
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Even if g_variant_get_va(), which we eventually call, checks on the
validity of the value argument, check it early to avoid surprises, such
as this intermittent FreeBSD test failure:
(/var/tmp/gitlab_runner/builds/3fe11159/0/GNOME/glib/_build/gio/tests/gdbus-connection:65788): GLib-CRITICAL **: 15:13:25.670: g_variant_get_va: assertion 'value != NULL' failed
Similar to 3837b83f, glibc memcmp is declared with the first two
arguments annotated as non-null via an attribute, which results in the
undefined behaviour sanitizer considering it to be UB to pass a null
pointer there (even if we are comparing 0 bytes, and hence not actually
dereferencing the pointer).
This shows up in /gvariant/serialiser/children when run with the
undefined behaviour sanitizer.
Signed-off-by: Simon McVittie <smcv@collabora.com>
glib/gvariant.c: In function ‘g_variant_new_strv’:
glib/gvariant.c:1563:17: error: comparison of integer expressions of different signedness: ‘gsize’ {aka ‘long unsigned int’} and ‘gssize’ {aka ‘long int’} [-Werror=sign-compare]
for (i = 0; i < length; i++)
^
glib/gvariant.c: In function ‘g_variant_new_objv’:
glib/gvariant.c:1699:17: error: comparison of integer expressions of different signedness: ‘gsize’ {aka ‘long unsigned int’} and ‘gssize’ {aka ‘long int’} [-Werror=sign-compare]
for (i = 0; i < length; i++)
^
glib/gvariant.c: In function ‘g_variant_new_bytestring_array’:
glib/gvariant.c:1939:17: error: comparison of integer expressions of different signedness: ‘gsize’ {aka ‘long unsigned int’} and ‘gssize’ {aka ‘long int’} [-Werror=sign-compare]
for (i = 0; i < length; i++)
^
Otherwise the GVariant would later fail internal alignment checks,
aborting the program.
If unaligned data is provided to (for example)
g_variant_new_from_data(), it will copy the data into a new aligned
allocation. This is slow, but better than crashing. If callers want
better performance, they should provide aligned data in their call, and
it will not be copied or reallocated.
Includes a unit test.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/1342
That should format these character classes correctly in the
documentation, and prevent them being interpreted by gtk-doc as (broken)
Markdown hyperlinks.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This fits better with the convention in the rest of GLib where arbitrary
8-bit values are represented as guint8, avoiding the potential confusing
of a name which references ‘char’s.
This is not an API break, as both guint8 and guchar are unconditionally
typedeffed to unsigned char.
https://gitlab.gnome.org/GNOME/glib/issues/896
gtk-doc doesn’t support them any more since it was ported to Markdown,
so they end up appearing in the generated documentation, which isn’t
great.
Mostly, they were used to split up things invisibly, which we can do in
other ways.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Reviewed-by: nobody
Clarify that the return value may be floating, or may not be (depends
on whether the input @value was in normal form).
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=741167
All glib/*.{c,h} files have been processed, as well as gtester-report.
12 of those files are not licensed under LGPL:
gbsearcharray.h
gconstructor.h
glibintl.h
gmirroringtable.h
gscripttable.h
gtranslit-data.h
gunibreak.h
gunichartables.h
gunicomp.h
gunidecomp.h
valgrind.h
win_iconv.c
Some of them are generated files, some are licensed under a BSD-style
license and win_iconv.c is in the public domain.
Sub-directories inside glib/:
deprecated/: processed in a previous commit
glib-mirroring-tab/: already LGPLv2.1+
gnulib/: not modified, the code is copied from gnulib
libcharset/: a copy
pcre/: a copy
tests/: processed in a previous commit
https://bugzilla.gnome.org/show_bug.cgi?id=776504
Reformatted the docs for G_VARIANT_TYPE_UINT64 to avoid having a
number in the beginning of the line, because apparently gtk-doc treats
that as a first element of the numbered list. The number being that
big probably makes gtk-doc to treat it as 1.
Fixed the g_variant_new_fixed_array documentation - it was partially
copy-pasted from the g_variant_get_fixed_array documentation.
The rest should be quite obvious.
https://bugzilla.gnome.org/show_bug.cgi?id=781830
If we have an input parameter (or return value) we need to use (nullable).
However, if it is an (inout) or (out) parameter, (optional) is sufficient.
It looks like (nullable) could be used for everything according to the
Annotation documentation, but (optional) is more specific.
The macro could be used at initialization time to avoid having an
unitialized dict, especially with g_auto variables.
The macro tries to be a bit more type-safe by making sure that the asv
parameter is actually "GVariant *".
https://bugzilla.gnome.org/show_bug.cgi?id=766370
The macro could be used at initialization time to avoid having an
unitialized builder, especially with g_auto variables.
The macro tries to be a bit more type-safe by making sure that the
variant_type parameter is actually "const GVariantType
*". Unfortunately I have no idea how to make it possible to also pass
a "const gchar *" parameter without warning.
https://bugzilla.gnome.org/show_bug.cgi?id=766370
There is no need to call g_variant_builder_clear() after the
g_variant_builder_end(). This is mentioned in docs of the former
function, but not in the docs of the latter one. Add them there too.
Inserts a paragraph in the start of the description
explaining briefly the concept of GVariant as a
variant datatypes using examples and explaining
a few use cases where GVariant can be useful.
https://bugzilla.gnome.org/show_bug.cgi?id=748806
Copy the flatten-first logic from g_variant_get(), and for the same
reason: if the user is requesting a direct pointer access to a
tree-based child inside of argument to this function then that child
could disappear later.
Forcing serialisation means that the pointer will remain valid as long
as the passed-in instance exists, which is the usual expectation with
GVariant API.
https://bugzilla.gnome.org/show_bug.cgi?id=755374
This confused me for a while, because it isn't the same as D-Bus.
Like GVariant, the D-Bus serialization needs an out-of-band
endianness and type indicator, but unlike GVariant, serialized
D-Bus objects encapsulate their own length (often by starting with
a byte-count). This does come at some redundancy cost, so I can see
why the more efficient GVariant format does this the way it does;
but it's a difference between D-Bus and GVariant that seems worth
calling out.
It's also relevant for the designers of file or message-framing
formats: with D-Bus serialization it would be feasible to say "the file
starts with a little-endian D-Bus variant, followed by...",
but in GVariant you wouldn't be able to deserialize the variant
unless you either assume that it extends to end-of-file, or have
an explicit length.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=736975
Reviewed-by: Ryan Lortie
Since we are no longer using sgml mode, using /* */ to
escape block comments inside examples does not work anymore.
Switch to using line comments with //
Since all element markup is now gone from the doc comments,
we can turn off the gtk-doc sgml mode, which means that from
now on, docbook markup is no longer allowed in doc comments.
To make this possible, we have to replace all remaining
entities in doc comments by their replacement text, & -> &
and so on.
