Once upon a time, we tried to return all possible certificate errors,
but it never actually worked reliably and nowadays we have given up.
This needs to be documented because a reasonable developer would not
expect it.
Because mistakes could be security-critical, I decided to copy the same
warning in several different places rather than relying only on
cross-referencese.
Use g_macro__has_attribute to detect it instead of
hardcoding __GNUC__ || __clang__. This adds support
for a few compiler and is consistent with the rest
of the gmacros.h file.
This is an attempt to fix a persistent error on the macOS CI:
```
Objective-C compiler for the host machine: cc (clang 10.0.0)
Objective-C linker for the host machine: APPLE ld 409.12
WARNING: No include directory found parsing "cc -xobjc -E -v -" output
meson.build:761:2: ERROR: Fatal warnings enabled, aborting
```
For example, seen on https://gitlab.gnome.org/GNOME/glib/-/jobs/1618966.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
These are known leaks, as they were being done in tests which were
checking precondition failures.
However, since we know what happens when the failures occur, we can
still free the input data reliably, so do that.
This improves the valgrind output for `actions` to show zero definite
leaks.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
The `actions` test previously waited an arbitrary 100ms for various
D-Bus messages to be sent/received, before checking the results of those
messages.
Normally, this would work, but on heavily loaded CI systems, it would
sometimes fail. For example,
https://gitlab.gnome.org/GNOME/glib/-/jobs/1611701.
Fix that by waiting for the condition being checked to evaluate to true,
rather than waiting an arbitrary period of time. On faster machines,
this will speed the tests up too.
Assume that the global default `GMainContext` is in use, so a
`GMainContext*` pointer doesn’t have to be passed around.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
gio/gcontenttype-win32.c: In function 'get_registry_classes_key':
gio/gcontenttype-win32.c:66:78: warning: comparison of integer expressions of different signedness: 'DWORD' {aka 'long unsigned int'} and 'int'
if (ExpandEnvironmentStringsW (wc_temp, wc_temp_expanded, len) == len)
^~
This allows the flag to allow interactive auth to be set. Previously, it
was unconditionally unset.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
glib.git/glib/garray.c: In function ‘g_array_new’:
glib.git/glib/garray.c:184:34: error: comparison is always true due to limited range of data type [-Werror=type-limits]
184 | g_return_val_if_fail (elt_size <= G_MAXSIZE / 2 - 1, NULL);
| ^~
glib.git/glib/gmacros.h:1090:25: note: in definition of macro ‘G_LIKELY’
1090 | #define G_LIKELY(expr) (expr)
| ^~~~
glib.git/glib/garray.c:184:3: note: in expansion of macro ‘g_return_val_if_fail’
184 | g_return_val_if_fail (elt_size <= G_MAXSIZE / 2 - 1, NULL);
| ^~~~~~~~~~~~~~~~~~~~
glib.git/glib/garray.c: In function ‘g_array_sized_new’:
glib.git/glib/garray.c:265:34: error: comparison is always true due to limited range of data type [-Werror=type-limits]
265 | g_return_val_if_fail (elt_size <= G_MAXSIZE, NULL);
| ^~
glib.git/glib/gmacros.h:1090:25: note: in definition of macro ‘G_LIKELY’
1090 | #define G_LIKELY(expr) (expr)
| ^~~~
glib.git/glib/garray.c:265:3: note: in expansion of macro ‘g_return_val_if_fail’
265 | g_return_val_if_fail (elt_size <= G_MAXSIZE, NULL);
| ^~~~~~~~~~~~~~~~~~~~
D-Bus has an upper limit on number of Match rules and it's rather easy to hit
with a big number of proxies with signal subscriptions. This happens with
NetworkManager with hundreds of devices or connection settings. By passing
G_DBUS_SIGNAL_FLAGS_NO_MATCH_RULE to g_dbus_connection_signal_subscribe(), the
user can call AddMatch with a less granular match instead of a match per every
proxy.
Tests subsequently added by Philip Withnall.
Fixes: #1109
The documentation about validity did not match the code. Since the code
hasn’t changed in a long time (since 1998 or 2011), change the
documentation to match it.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2520
It’s a programmer error for `NULL` to reach `is_group_name()` or
`is_key_name()`, so rework the preconditions so that all programmer
error checks are wrapped in a `g_return_if_fail()`. The coverage
scanning is set up to ignore anything inside that.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
`g_key_file_parse_key_value_pair()` checks that both of these are
non-NULL on entry, and they can’t be modified between then and here.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This should introduce no functional changes, but will remove an
unreachable branch in `g_key_file_locale_is_interesting()`:
`checked_locales` indicates whether `locales` has been initialised (and
it can be initialised to `NULL`), so there’s no point in checking
`locales` itself if `checked_locales` is checked.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Instead compare it inline. This should avoid a lot of allocations in key
files with lots of translations (such as desktop files).
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This avoids allocating a copy of the value in the case that it’s for a
locale which is uninteresting.
This should speed up parsing of key files with large numbers of
translations, when only the translations for certain locales are wanted.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This doesn’t affect performance in the normal case of a valid key file,
but does improve performance when handling largely-invalid key files.
oss-fuzz#31796
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This was harmless, as it was always +1 too long, so included the
trailing nul terminator. However, upcoming changes will start to use it
in a context where there is no nul terminator.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
The documentation wasn’t clear about whether it did that, or ignored nul
bytes and continued to `n` bytes regardless.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Rather than looking for the group node by comparing each name in the
linked list of `GKeyFileGroup` instances, look up the `GKeyFileGroup` in
the hash table, then look up its `GList` node by pointer.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
