They don’t need to be listed there in order to be built, and doing so
just means they get pulled into the `g-ir-scanner` command for building
`GLib-2.0.gir` and their contents end up being listed as public
introspectable API, which is not what we want.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3231
Otherwise, `CFLAGS='-Wall -Werror' meson build` fails with:
...
Command line: `cc ./glib/build/meson-private/tmp7iwplrgi/testfile.c -o ./glib/build/meson-private/tmp7iwplrgi/output.obj -c -O3 -Werror -Wall -D_FILE_OFFSET_BITS=64 -O0 -std=gnu99` -> 1
stderr:
./glib/build/meson-private/tmp7iwplrgi/testfile.c: In function 'main':
./glib/build/meson-private/tmp7iwplrgi/testfile.c:83:21: error: unused variable 'y' [-Werror=unused-variable]
83 | long double y = frexpl (x, &exp);
| ^
cc1: all warnings being treated as errors
-----------
Checking if "frexpl prototype can be re-listed" compiles: NO
glib/gnulib/meson.build:316:2: ERROR: Problem encountered: frexpl() is missing or broken beyond repair, and we have nothing to replace it with
It’s reasonable for the `main()` function in a test suite to pass
ownership of some test data to `g_test_add_data_func_full()`, along with
a `GDestroyNotify`, and rely on GTest to free the data after all tests
have been run.
Unfortunately that only worked if the test was run, and not skipped
before its test function was called. This could happen if, for example,
it had `/subprocess` in its path.
Fix that by always freeing the test data. This required reworking how
tests are skipped, slightly, to bring all the logic for that within
`test_case_run()`, so that it could always handle the memory management.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3248
The function arguments index_ and length could lead to a sum which is
larger than G_MAXUINT, possibly leading to out of boundary accesses
in array_remove_range functions.
Signed-off-by: Tobias Stoeckmann <tobias@stoeckmann.org>
Fixes: #3240
It's not obvious why we wouldn't use g_quark_try_string(). Add a code
comment that this is intentional and a reference for how to find out
more.
Also, fix typo in another code comment.
The amount of used memory should stay in relation to the number of
entries we have. If we delete most (75%) of the entries, let's also
reallocate the buffer down to 50% of its size.
datalist_append() now starts with 2 elements. This works together with
the shrinking. If we only have one entry left, we will shrink the buffer
back to size 2. In general, d->alloc is always a power of two (unless it
overflows after G_MAXUINT32/2, which we assume will never happen).
The previous buffer growth strategy of never shrinking is not
necessarily bad. It has the advantage to not require any checks for
shrinking, and it works well in cases where the amount of data actually
does not shrink (as we'd often expect).
Also, it's questionable what a realloc() to a smaller size really
brings. Is that really gonna help and will the allocator do something
useful?
Anyway. This patch introduces shrinking. The check for whether to shrink
changes from `if (d->len == 0)` to `if (d->len <= d->alloc / 4u)`, which
is probably cheap even if most of the time we don't need to shrink. For
most cases, that's the only change that this patch brings. However, once
we find out that 75% of the buffer are empty, calling realloc() seems a
sensible thing to do.
The main point here is to reuse datalist_remove() and datalist_shrink().
Especially, datalist_shrink() will become more interesting next, when it
actually shrinks the buffer.
Also, I find the previous implementation with "data_end" confusing.
Instead, only use index "i_data" to iterate over the data.
Extract helper functions datalist_remove() and datalist_shrink(). This
is to reduce duplicate code, but also to have a default way how to do
this.
In particular, later datalist_shrink() might do more aggressive
shrinking. We need to have that code in one place.
g_datalist_unlock() is probably faster than g_datalist_unlock_and_set().
Move the "if (data)" check (that we anyway had) earlier, so we can
call g_datalist_unlock() and return early.
If too many keys are requested, they temporary buffer is allocated
on the heap. There is no problem in principle, to remove more than
16 keys.
Well, the problem is that GData tracks entries in a linear list, so
performance will degrade when it grows too much. That is a problem,
and users should be careful to not add unreasonably many keys. But it's
not the task of g_datalist_id_remove_multiple() to decide what is
reasonable.
This limitation was present from the beginning, in commit 0415bf94127c
('Add g_datalist_id_remove_multiple'). It's no longer necessary since
commit eada6be364b4 ('gdataset: cleanup g_data_remove_internal()').
GDataSet is mainly used by GObject. Usually, when we access the private
data there, we already hold another lock around the GObject.
For example, before accessing quark_toggle_refs, we take a
OPTIONAL_BIT_LOCK_TOGGLE_REFS lock. That makes sense, because we anyway
need to protect access to the ToggleRefStack. By holding such an
external mutex around several GData operations, we achieve atomic
updates.
However, there is a (performance) use case to update the qdata
atomically, without such additional lock. The GData already holds a lock
while updating the data. Add a new g_datalist_id_update_atomic()
function, that can invoke a callback while holding that lock.
This will be used by GObject. The benefit is that we can access the
GData atomically, without requiring another mutex around it.
For example, a common pattern is to request some GData entry, and if
it's not yet allocated, to allocate it. This requires to take the GData
bitlock twice. With this API, the callback can allocate the data if no
entry exists yet.
also, make the global variable "static const". That may allow the linker
to place the variable into read-only memory, so we are a bit more confident
that it cannot be modified.
g_strndup() internally uses strncpy(), while g_strdup() uses memcpy().
Most likely, memcpy() is faster.
Instead of strlen()+g_strndup(), use g_strdup() as we don't need the
length.
This fixes many things from the port to gi-docgen, but also improves
documentation more generally.
Main improvements/fixes:
- Fix links to functions, constants, etc.
- Rewrite code syntax to work with Markdown
- Reduce indentation (do not indent by 4 to prevent code blocks)
- Remove redundant text such as "can be NULL" or "should be freed"
- Move text from large return info texts to main function text
- Remove periods at the end of parameter and return descriptions
- Do not capitalize the first word of a parameter or return description
- Try to improve consistency between docs for similar functions
- Convert %TRUE and %FALSE into true and false
- Convert other uses of `%` and `#` into inline code
Helps: #3037
Fixes broken links, and removes `%` and `#` notation in favor of inline
code, and limits indentation to two to prevent accidental formatting.
Fixes some style issues too, mainly removing periods at the end of
parameter and return descriptions.
Also removes trailing whitespace from the doc comments.
Helps: #3037
Saying that a GtkWidget is a GtkWidget is trivially true, but not the
point we were trying to make here.
Fixes: b5c07063 "docs: Use code for class names in links"
Signed-off-by: Simon McVittie <smcv@collabora.com>
The test cancellation timeout was being tested twice, once only when run
with `-m thorough`. Seems a bit pointless.
Merge the two tests and use the smaller timeout values from the two, so
the test suite doesn’t run any more slowly than it did.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
`g_test_init()` needs to be called before custom command line handling
so it has a chance to strip out the arguments it handles.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
This avoids four coredumps being processed for every run of the
`testing` unit tests (which test `GTest`).
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
It is common to declare a mutex locker variable and to not use it in the
scope. That causes clang to warn about unused variable which is not
entirely true since the cleanup function IS the intended usage.
Work around that issue with a new macro that uses G_GNUC_UNUSED and
has the extra advantage of being less verbose.
Fixes: #3223.
FreeBSD iconv by default handles input characters that are not
representable in the destination character set by emitting a replacement
character such as '?'. While this appears to be the POSIX mandated
behaviour it does not match GNU behaviour and causes the gconvert test
to fail in the `test_one_half` testcase. Fortunately FreeBSD provides a
iconvctl flag to request this behaviour to match GNU iconv.
See https://github.com/freebsd/freebsd-src/commit/7c5b23111c5fd199204
