It's helpful for the assertion message to say what we were expecting and
what we actually got. It's also useful to have g_test_message()
diagnostics to indicate how far into the test we were.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Previously we didn't test these at all, which made it hard to determine
whether %Ec, %EC had appropriate output on platforms where era-based
dates are unsupported. Now we do, and we can observe that on platforms
with no support for era-based dates, %c matches %Ec and %C matches %EC,
as desired.
Signed-off-by: Simon McVittie <smcv@collabora.com>
I can't read Japanese, but these match the output of:
env TZ=UTC LC_ALL=ja_JP.eucjp date -d2009-10-24T00:00:00Z '+%c' | iconv -f eucjp -t UTF-8
env TZ=UTC LC_ALL=ja_JP.eucjp date -d2009-10-24T00:00:00Z '+%C' | iconv -f eucjp -t UTF-8
which seem like a reasonable thing to use as a reference.
According to Google Translate, 平成 refers to the Heisei era, which was
current during 2009, and seems unreasonable to expect as output on a
platform where era-based dates are unsupported.
Resolves: https://gitlab.gnome.org/GNOME/glib/-/issues/3252
Signed-off-by: Simon McVittie <smcv@collabora.com>
Maintain them in separate lists within `meson.build`. This makes no
functional difference at the moment, but will be used in an upcoming
commit to generate separate GIR files per platform.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3037
This reverts commit 50d432c77b.
The platform-specific headers of GLib and Gio are now introspected
separately, so the documentation for them can be built separately, and
this workaround is no longer needed.
Helps: #3037
The docs for this should match the docs for `g_unix_open_pipe()`, which
it calls.
Inspired by !3911.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Using FD_CLOEXEC here is now deprecated. Keep exactly one call with
FD_CLOEXEC, in test_pipe_fd_cloexec().
Signed-off-by: Simon McVittie <smcv@collabora.com>
The copy of this function that moved to glib-unix.c still needs to
implement the fdwalk-style interface, but this copy does not, allowing
us to turn it into a very simple syscall wrapper. Its remaining callers
never check for errors, and it never failed anyway, so remove the
returned value.
Signed-off-by: Simon McVittie <smcv@collabora.com>
These are the same as Linux `close_range (lowfd, ~0U, 0)` and
`close_range (lowfd, ~0U, CLOSE_RANGE_CLOEXEC)`, but portable.
Unlike some implementations of BSD closefrom(3), they are
async-signal-safe.
The implementations were moved from the GSpawn code, which already
needs all of this functionality anyway, with the exception of
set_cloexec() which was copied (leading to some minor duplication,
but it's very simple).
Resolves: https://gitlab.gnome.org/GNOME/glib/-/issues/3247
Signed-off-by: Simon McVittie <smcv@collabora.com>
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 0415bf9412
('Add g_datalist_id_remove_multiple'). It's no longer necessary since
commit eada6be364 ('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
Usually, after g_pointer_bit_lock() we want to read the pointer that we
have. In many cases, when we g_pointer_bit_lock() a pointer, we can
access it afterwards without atomic, as nobody is going to modify the
pointer then.
However, gdataset also supports g_datalist_set_flags(), so the pointer
may change at any time and we must always use atomics to read it. For
that reason, g_datalist_lock_and_get() does an atomic read right after
g_pointer_bit_lock().
g_pointer_bit_lock() can easily access the value that it just set. Add
g_pointer_bit_lock_and_get() which can return the value that gets set
afterwards.
Aside from saving the second atomic-get in certain scenarios, the
returned value is also atomically the one that we just set.
In all cases after taking the lock with g_datalist_lock(), we also
get the pointer. And it hardly makes sense otherwise.
Replace g_datalist_lock() by g_datalist_lock_and_get() which does
both steps in one.
- only use gnewa0() for up to 400 bytes (arbitrarily chosen as
something that is probably small enough to cover most small tasks
while fitting easily on the stack). Otherwise fallback to g_new0().
- don't do intermediate G_DATALIST_SET_POINTER(). Set to NULL
afterwards with g_datalist_unlock_and_set().
- move the g_free(d) after releasing the lock on datalist.
- when setting datalist to NULL, do it at the end with
g_datalist_unlock_and_set() to avoid the additional atomic
operations.
- when freeing the old "d", do that after releasing the bit
lock.
The previous code was in practice correct.
(((guintptr) ptr) | ((gsize) mask))
works even if gsize is smaller than guintptr. And while the C standard
only guarantees that cast between uintptr_t and void* works, on
reasonable compilers it works to directly cast uintptr_t to GData*.
Still, no need for such uncertainty. Just be clear about the involved
types (use guintptr throughout) and cast first to (gpointer).
g_datalist_clear_i() had only one caller, altough the code comment made
it sound as if in the past there were more.
A function that has only one caller, and then needs a code comment to
explain the context in which it is called, makes the code more complicated
than necessary.
Especially since the function expects to be called with a global lock
held, and then unlocks and relocks. Spreading such things to another
function (which is only used once) makes code harder to follow.
Inline the function, so that we can see all the (trivial) code at one place.
This saves an additional atomic set.
Also, changing the pointer before the unlock can awake a blocked thread,
but at this point, the lock is still held (and the thread may need to
sleep again). This can be avoided.
The existing g_pointer_bit_lock() and g_pointer_bit_unlock() API
requires the user to understand/reimplement how bits of the pointer get
mangled. Add helper functions for that.
The useful thing to do with g_pointer_bit_lock() API is to get/set
pointers while having it locked. For example, to set the pointer a user
can do:
g_pointer_bit_lock (&lockptr, lock_bit);
ptr2 = set_bit_pointer_as_if_locked(ptr, lock_bit);
g_atomic_pointer_set (&lockptr, ptr2);
g_pointer_bit_unlock (&lockptr, lock_bit);
That has several problems:
- it requires one extra atomic operations (3 instead of 2, in the
non-contended case).
- the first g_atomic_pointer_set() already wakes blocked threads,
which find themselves still being locked and needs to go back to
sleep.
- the user needs to re-implement how bit-locking mangles the pointer so
that it looks as if it were locked.
- while the user tries to re-implement what glib does to mangle the
pointer for bitlocking, there is no immediate guarantee that they get
it right.
Now we can do instead:
g_pointer_bit_lock(&lockptr, lock_bit);
g_pointer_bit_unlock_and_set(&lockptr, lock_bit, ptr, 0);
This will also emit a critical if @ptr has the locked bit set.
g_pointer_bit_lock() really only works with pointers that have a certain
alignment, and the lowest bits unset. Otherwise, there is no space to
encode both the locking and all pointer values. The new assertion helps
to catch such bugs.
Also, g_pointer_bit_lock_mask_ptr() is here, so we can do:
g_pointer_bit_lock(&lockptr, lock_bit);
/* set a pointer separately, when g_pointer_bit_unlock_and_set() is unsuitable. */
g_atomic_pointer_set(&lockptr, g_pointer_bit_lock_mask_ptr(ptr, lock_bit, TRUE, 0, NULL));
...
g_pointer_bit_unlock(&lockptr, lock_bit);
and:
g_pointer_bit_lock(&lockptr, lock_bit);
/* read the real pointer after getting the lock. */
ptr = g_pointer_bit_lock_mask_ptr(lockptr, lock_bit, FALSE, 0, NULL));
...
g_pointer_bit_unlock(&lockptr, lock_bit);
While glibc is fine with it (and returns a `NULL` pointer), technically
it’s implementation-defined behaviour according to POSIX, so it’s best
avoided.
See
https://pubs.opengroup.org/onlinepubs/9699919799/functions/posix_memalign.html.
In particular, valgrind will warn about it, which is causing failures of
the gdbus-codegen tests when valgrind is enabled. For example,
https://gitlab.gnome.org/GNOME/glib/-/jobs/3460673 gives
```
==15276== posix_memalign() invalid size value: 0
==15276== at 0x484B7BC: posix_memalign (vg_replace_malloc.c:2099)
==15276== by 0x49320B2: g_variant_new_from_bytes (gvariant-core.c:629)
==15276== by 0x4931853: g_variant_new_from_data (gvariant.c:6226)
==15276== by 0x4B9A951: g_dbus_gvalue_to_gvariant (gdbusutils.c:708)
==15276== by 0x41BD15: _foo_igen_bat_skeleton_handle_get_property (gdbus-test-codegen-generated.c:13503)
==15276== by 0x41BFAF: foo_igen_bat_skeleton_dbus_interface_get_properties (gdbus-test-codegen-generated.c:13582)
…
```
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3228
This doesn't appear to work reliably on s390x and ppc64, returning
the results that were expected without %E or intermittently crashing.
It seems that on little-endian 64-bit, the intptr_t returned by the
undocumented _NL_TIME_ERA_NUM_ENTRIES correctly has the number of entries
in its low-order half (at the time of writing, 0x0000'0000'0000'000b for
Japan), but on big-endian 64-bit, it has the number of entries in its
high-order half instead (for example 0x0000'000b'0000'0000 for Japan),
with the low-order half being all-zero or possibly uninitialized.
Making this reliable will require some sort of defined API from glibc.
Helps: https://gitlab.gnome.org/GNOME/glib/-/issues/3225
Bug-Debian: https://bugs.debian.org/1060735
Signed-off-by: Simon McVittie <smcv@collabora.com>
We only care about the introspection data for documentation purposes;
the GStaticMutex and GStaticRecMutex types are long since deprecated,
and they cannot be used from language bindings anyway, so their size is
immaterial.
Fixes: #3222
Previously, the girs and typelibs generated from gobject-introspection
ommited the deprecated apis, however we want them annotated for
documentation purposes.
Skip the deprecated gthead api so they do not make it into the
typelibs which caused problems as not all the symbols exist.
See https://gitlab.gnome.org/GNOME/gjs/-/issues/595
Introduce g_log_writer_syslog() that is suitable for use as a
GLogWriterFunc and sends the log message to the syslog daemon.
Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
_Thread_local is also C11, so possibly other compilers would also support
it.
However, since not *all* compilers support it, it can anyway only be
used as optimization and conditional asserts. As such, the current
detection based on __GNUC__ to only support gcc (and clang) is good
enough.
This was done manually, but the changes are very repetitive. There are
some minor rewordings/formatting tweaks included. The bulk of the
changes are to the linking syntax.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3037
There is no reason for key and value to have different annotations.
Both may return NULL as a valid value.
gpointer typed parameters are nullable by convention, so there is
no change here. The (nullable) annotation is just for humans really.
To make it match its definition and documentation comment. This fixes a
g-ir-scanner warning.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3037
Extended error domains can never be unregistered, so these closures
have to be around forever.
Fixes some g-ir-scanner warnings.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3037
`GByteArray` is a bit odd in that it allows call-chaining. All the
instances of that were missing a `(transfer none)` annotation though.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3037
This fixes a warning from g-ir-scanner as the declaration and
documentation comment didn’t match.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3037
This was pointed out in the review for !3696 but owing to a mistake by
me, the fix was not included in the version of the MR which was merged.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3119
I wrote the changes before clarifying the copyright status of my
contract with the GNOME Foundation, and forgot to update them.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3119
It was previously set (by default) to `C`, so this commit doesn’t change
the locale behaviour of the tests, but does ensure that messages printed
by the tests are correctly formatted in UTF-8 rather than transliterated
to ASCII.
That makes interpreting test output easier.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
The `%E` modifier causes dates to be formatted using an alternative era
representation for years. This doesn’t do anything for most dates, but
in locales such as Thai and Japanese it causes years to be printed using
era names.
In Thai, this means the Thai solar calendar
(https://en.wikipedia.org/wiki/Thai_solar_calendar). In Japanese, this
means Japanese era names
(https://en.wikipedia.org/wiki/Japanese_era_name).
The `%E` modifier syntax follows what’s supported in glibc — see
nl_langinfo(3).
Supporting this is quite involved, as it means loading the `ERA`
description from libc and parsing it.
Unit tests are included.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
Fixes: #3119
Point people to the official PCRE documentation instead, which is going
to be more up to date. This saves us periodically having to copy in and
reformat the PCRE documentation.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3037
Move them to a separate page as they don’t really have a ‘class’ struct
each to hang docs off.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3037
Move it to a separate page, with a massive great list of all the misc
utils. Not a great documentation page, but equivalent to what we had
before, and it can be improved in future.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3037
All this API is internal to GLib, so the section was never actually
exposed in the public API documentation. Keep the documentation, just
don’t tag it as a SECTION.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3037
Move it to a separate documentation file, since most of what’s covered
isn’t introspectable.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3037
Move it to a separate page so the difference between `g_rand_*()` and
`g_random_*()` can be explained.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3037
It was one paragraph which mentioned `GHookList` and `GHook`, both of
which have their own adequate documentation sections.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3037
Move it to a separate page so more detail can be provided about all the
groups of API.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3037
Move it to a separate page so an overview of the deprecated threading
API can be given.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3037
My GTK testlogs are filled with
GLib-DEBUG: g_unix_open_pipe() called with FD_CLOEXEC; please migrate to using O_CLOEXEC instead
Lets take the hint, and migrate to using O_CLOEXEC.
As with `test-printf`, the `vasprintf()` placeholder checks on BSDs
(including macOS) are less strict than on Linux (glibc), so the expected
critical message is not seen.
Change the test to not expect it on BSDs.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3187
It was previously possible for this to silently fail, which isn’t great
for program correctness. Instead, raise a critical warning so the
programmer knows to either validate their Unicode inputs, or fix their
format placeholders.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3187
It’s possible for the function to fail for the same reasons
`g_vasprintf()` would fail.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3187
As per the previous commit, it’s possible for
`g_printf_string_upper_bound()` to return an error. We need to catch and
handle that error in `g_vasprintf()` to avoid it trying to write to a
`NULL` string allocation and crashing.
So, call `g_vsnprintf()` directly instead of calling
`g_printf_string_upper_bound()`, so that the error case can be handled.
There was already a test for some of this behaviour
(`test_vasprintf_invalid_format_placeholder()`). Because it tested an
invalid format string, the `_g_vsprintf()` call bailed out before
checking whether the buffer it had been passed was `NULL`. The new test
has a valid format string, but an invalid arg.
When running the tests locally, I have disabled the `USE_SYSTEM_PRINTF`
and `HAVE_VASPRINTF` code paths in `g_vasprintf()`.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3187
Spotted in https://gitlab.gnome.org/GNOME/glib/-/issues/3187.
In an ideal world, this API would have been designed with an error
return path to begin with — perhaps by returning a `GError` or a
`gssize`. We can’t change the API now, though, which leads to this
slightly awkward “0 indicates an error or success” pattern.
I think that’s justified in this case because:
- This API does not see much use.
- Format strings tend to be literals, and almost always are
non-zero-length, so it tends to be statically possible to determine
that the function won’t return zero on success.
- If callers do need to differentiate the two zero return value cases,
they can just call `g_vsnprintf()` directly instead.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3187
The test needs to call `ftruncate64()` (not `ftruncate()`) to guarantee
it’s using the 64-bit version on Linux, but this doesn’t exist on other
platforms.
Test to see if it exists and, if not, skip the test.
Fixes commit cf5e371c67, and fixes CI
failures like https://gitlab.gnome.org/GNOME/glib/-/pipelines/602930.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
The win32-specific APIs in GLib are only defined when building for
Windows. Unfortunately, this means they can not show up in `GLib-2.0.gir`
if it’s build on Linux (which is what mostly happens).
Consequently, that means they’re not present in the API documentation,
which is a bit of a problem.
Make the symbols in the header available on other platforms
(particularly Linux) if building with `g-ir-scanner` (but not
otherwise). This means the win32 symbols show up in `GLib-2.0.gir` and
hence in the documentation.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3037
On certain platforms where file size (off_t) can be truncated when assigning to
gsize, get_contents_regfile() may use the truncated size as the size to read. Add
an explicit check to raise an error in such cases.
G_FILE_ERROR_FAILED will be raised in this case, aligning with behavior for other
cases.
This generally affects 32-bit non-Win32 platforms.
Just as they were ignored under gtk-doc, ignore them when scanning the
sources using `g-ir-scanner`, and make it look at the full function
declarations instead.
This fixes inclusion of functions like `g_creat()` in the documentation.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3037
This allows the methods for `GDir` to be introspected. While we don’t
expect languages which use the introspection bindings to use `GDir`,
full introspection support is necessary for the `GDir` documentation to
be correctly built with gi-docgen.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3037
All GLib tests normally respect `TMPDIR` for writing their temporary
files to. The utils test, however, contained a hack which overwrote
`TMPDIR` so that it could test the behaviour of `g_get_tmp_dir()` for
regressions.
Unfortunately, that hack affected the whole `utils` test suite, not just
the one regression test.
Use the new `g_test_trap_subprocess_with_envp()` API to allow the
regression test to be run as a subprocess with its environment modified,
which allows us to remove the hack affecting the rest of the test suite.
Spotted in
https://gitlab.gnome.org/GNOME/glib/-/issues/3179#note_1925161.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
This is a variant of `g_test_trap_subprocess()` which allows the
environment for the child process to be specified. This is quite useful
when you want to test code which reads environment variables, as it’s
not safe to set those after the start of `main()`.
This will be useful within and outwith GLib for testing such code.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #1618
The problem is that resetting the environment of a
proccess is not safe, this is mentioned in the man
pages of the setenv, and also by the concept:
when we get a constant string returned by the getenv,
we need to be guaranteed that this string will exist
during all that time we are using it. While setting
the same env var to another value destroys this string
inside of libc.
Now looking at the should_drop_message(), we can see
that it just gets the environment on every call. Getting
the environment is safe, but however there's no safe way
to switch the logging domains selection: setenv can't be
used because of the reasons listed above.
That is why g_log_writer_default_set_debug_domains() is
needed: it's just a safe replacement for the setenv in this case.
Now should_drop_message() still reads the environment, but
does so only on the first call, after that the domains are
stored internally, and can only be changed by
g_log_writer_default_set_debug_domains().
This also means that now resetting G_MESSAGES_DEBUG env
var in runtime has no effect. But in any case this is not
what the user should do, because resetting the environment
in runtime is not correct.
We presumably want the fallback string used when we cannot determine
the program name to contain balanced angle brackets, as it did before
commit 7098250e.
Fixes: 7098250e "gutils: avoid race setting prgname from g_option_context_parse()/g_application_run()"
Signed-off-by: Simon McVittie <smcv@collabora.com>
g_option_context_parse()/g_application_run()/g_test_init() for
convenience also call g_set_prgname(), when the prgname is unset at this
point. This was racy.
Fix the race by using an atomic compare-and-exchange and only reset the
value, if it is unset still.
g_set_application_name() guards against being reset, but it doesn't
remember whether it was set, it only checks whether g_application_name
was set to non-NULL. When allowing g_set_application_name(NULL) that leads
to odd behaviors, like:
g_set_application_name(NULL);
g_set_application_name("foo");
would not warn.
Disallow that and assert against a NULL application_name.
Note that application_name argument is also not marked as "(nullable)".
Modify all the similar Python test wrappers to set
`G_DEBUG=fatal-warnings` in the environment of the program being tested,
so we can catch unexpected warnings/criticals.
Adding this because I noticed it was missing, not because I noticed a
warning/critical was being ignored.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
Mention that ready time being equal to the current time means the source
will fire immediately.
Related to https://gitlab.gnome.org/GNOME/glib/-/issues/3148
Signed-off-by: Sergey Bugaev <bugaevc@gmail.com>
Instead of tracking a "(guint,GSource*)" tuple in the "context->sources"
dictionary, only track pointers to the "source_id".
With this we use the GHashTable as Set (g_hash_table_add()), which is
optimized and avoids storing a separate value array.
It's simple enough to do, because there are literally 5 references to
"context->sources". It's easy to review those usages and reason that the
handling is correct.
While at it, in g_main_context_find_source_by_id() move the check for
SOURCE_DESTROYED() inside the lock. It's not obvious that doing this
without a lock was correct in every case. But doing the check with
a lock should be fast enough to not worry about whether it's absolutely
necessary.
We have g_int_hash()/g_int_equal(), which in practice might also work
with with pointers to unsigned integers. However, according to strict
interpretation of C, I think it is not valid to conflate the two.
Even if it were valid in all cases that we want to support, we should
still have separate g_uint_{hash,equal} functions (e.g. by just #define
them to their underlying g_int_{hash,equal} implementations).
Add instead internal hash/equal functions for guint.
Previously thread-pool-slow ran a single test which encoded a state
machine and polling timer to run 8 different sub-tests and check for
their exit conditions.
This was a bit ugly, and since the timer ran at 1s granularity, several
of the tests completed quite fast and then hang around for most of 1s
before finishing and moving to the next test.
Split the test functions up into separate GTest tests, and split the
state machine up between the test functions. All of the `GMainLoop`
handling is actually only needed for the `test_threadpool_idle_time()`
test.
This reduces the overall test runtime from 36s to 19s on my machine,
with 17s of that being spent in `test_threadpool_idle_time()`.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
Helps: #2810
This makes things a bit more maintainable, as there’s less global state
to worry about.
It introduces no functional changes.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
The race was already acknowledged in the code (via `last_failed`): the
thread pool starts dequeuing jobs as soon as it’s created, so it’s
dequeuing the sorted thread IDs while they’re still being enqueued and
sorted. This can lead to them being dequeued out of the expected order
if new thread IDs are enqueued out of order, which is possible because
they’re randomly generated.
The test tried to handle this by allowing one out-of-order dequeue, but
it looks like the race can race hard enough that multiple out-of-order
dequeues are possible.
Fix that by only starting to dequeue the jobs from the thread pool once
they’ve all been enqueued and put in a total order.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
Fixes: #2810
If the string of one log domain is contained in
another, it was printing both.
For example, if G_MESSAGES_DEBUG is "Gtkspecial",
it would also keep the logs of the "Gtk" domain
The weak symbol resolution doesn’t seem to work (see
https://gitlab.gnome.org/GNOME/glib/-/jobs/3265405):
```
Undefined symbols for architecture x86_64:
"___lsan_enable", referenced from:
_g_leak_sanitizer_is_supported in gutils.c.o
"___lsan_ignore_object", referenced from:
_g_ignore_leak in gquark.c.o
_g_ignore_leak in gthreadpool.c.o
_g_ignore_leak in gutils.c.o
_g_leak_sanitizer_is_supported in gutils.c.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
```
See !3672
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
GLib ignores various leaks that we don't consider as such (like the
default gio modules) via the LSAN public interface, however those cases
are always ignored when using a non-ASAN compiled glib is used by an
ASAN-compiled binary.
This makes all the GLib-related programs to fail because of false
positive leaks.
To avoid this, use the gcc extension for weak linking so that we can
control ASAN and LSAN only if the symbols they provide are actually
available at runtime.
On CHERI-enabled systems we use uintptr_t as the underlying storage for
GType and therefore casting to gsize strips the upper bits from a pointer.
Fix this by casting via uintptr_t instead and introduce a new set of
macros to convert between GType and pointers.
Currently, the introspection data for GLib and its sub-libraries is
generated by gobject-introspection, to avoid the cyclic dependency
between the two projects.
Since gobject-introspection is generally available on installed systems,
we can check for its presence, and generate the introspection data
directly from GLib.
This does introduce a cyclic dependency, which is why it's possible to
build GLib without introspection, then build gobject-introspection, and
finally rebuild GLib.
By having introspection data available during the GLib build, we can do
things like generating documentation; validating newly added API; and
close the loop between adding new API and it becoming available to non-C
consumers of the C ABI (i.e. language bindings).
The alt-digits are loaded from `nl_langinfo()` in a `GOnce` section,
which means `nl_langinfo()` is not re-queried after the process changes
locale (if that happens).
So, change the `GOnce` to a mutex and store the locale of the alt-digits
alongside them. This will introduce contention when calling
`format_number()` is called, but how often are multiple threads trying
to format dates at the same time?
If this does get highlighted as a performance problem, the other
approach I considered was a `GPrivate` struct containing all the
locale-specific cached data. That comes at the cost of using a
`GPrivate` slot (although that’s only particularly expensive on Windows,
and the locale code is quite different for Windows, so perhaps that
could be avoided entirely). It does mean that all locale printing could
be lock-free and still safely update cached data on a locale change.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
When calling `g_file_set_contents_full()` without
`G_FILE_SET_CONTENTS_CONSISTENT`, the file is written by opening it,
`write()`ing to it, then closing it.
This is fine as long as the file is not longer than the new content you
want to set its contents to. If it is, the last bit of the old content
remains, because `g_file_set_contents_full()` was missing an
`ftruncate()` call.
Fix that, and change the tests to catch truncation failures in future.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #3144
The Windows x64 ABI follows the LLP64 model, so unsigned long int is 32 bits
Fixes the following warnings when compiling for Windows x64:
../glib/gobject/gatomicarray.c:85:3: warning: cast to smaller integer type 'unsigned long' from 'gpointer' (aka 'void *') [-Wvoid-pointer-to-int-cast]
VALGRIND_MALLOCLIKE_BLOCK (mem, real_size - sizeof (GAtomicArrayMetadata),
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../glib/glib/valgrind.h:6479:5: note: expanded from macro 'VALGRIND_MALLOCLIKE_BLOCK'
VALGRIND_DO_CLIENT_REQUEST_STMT(VG_USERREQ__MALLOCLIKE_BLOCK, \
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../glib/glib/valgrind.h:203:15: note: expanded from macro 'VALGRIND_DO_CLIENT_REQUEST_STMT'
do { (void) VALGRIND_DO_CLIENT_REQUEST_EXPR(0, \
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../glib/glib/valgrind.h:417:20: note: expanded from macro 'VALGRIND_DO_CLIENT_REQUEST_EXPR'
_zzq_args[1] = (unsigned long int)(_zzq_arg1); \
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
See https://bugs.kde.org/show_bug.cgi?id=427146
g_strv_builder_take() allows to transfer ownership of the passed in
string.
This can be useful to avoid additional allocations when using functions
that transfer ownership to the caller like g_strdup_printf().
The testcase uses g_strv_builder_take and g_strv_builder_add to demo
that calls can be mixed.
We were initializing a DWORD (unsigned 32 bit) with a constant
of bigger rank (G_MAXSIZE) on 64 bit systems.
Fixes the following warnings on CLang when compiling for x64:
../glib/glib/tests/win32.c:47:14: warning: implicit conversion from 'unsigned long long' to 'DWORD' (aka 'unsigned long') changes value from 18446744073709551615 to 4294967295 [-Wconstant-conversion]
DWORD bp = G_MAXSIZE;
~~ ^~~~~~~~~
glib/glibconfig.h:88:19: note: expanded from macro 'G_MAXSIZE'
#define G_MAXSIZE G_MAXUINT64
^~~~~~~~~~~
../glib/glib/gtypes.h:107:21: note: expanded from macro 'G_MAXUINT64'
#define G_MAXUINT64 G_GUINT64_CONSTANT(0xffffffffffffffff)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
glib/glibconfig.h:69:52: note: expanded from macro 'G_GUINT64_CONSTANT'
#define G_GUINT64_CONSTANT(val) (G_GNUC_EXTENSION (val##ULL))
^~~~~~~~
<scratch space>:96:1: note: expanded from here
0xffffffffffffffffULL
^~~~~~~~~~~~~~~~~~~~~
Many toolchain did not change the definition of NULL to avoid introducing
breaking changes in existing codebases. For example, on Windows NULL is
0 (int) regardless of the C++ standard in use.
Fixes the following warnings on CLang when compiling for Windows:
../glib/glib/tests/cxx.cpp:539:34: warning: missing sentinel in function call [-Wsentinel]
g_test_init (&argc, &argv, NULL);
^
, nullptr
../glib/glib/gtestutils.h:298:9: note: function has been explicitly marked sentinel here
void g_test_init (int *argc,
^
../glib/gio/tests/cxx.cpp:62:34: warning: missing sentinel in function call [-Wsentinel]
g_test_init (&argc, &argv, NULL);
^
, nullptr
../glib/glib/gtestutils.h:298:9: note: function has been explicitly marked sentinel here
void g_test_init (int *argc,
^
