`#define G_GNUC_NORETURN __attribute__((__noreturn__))` was previously under
`#if G_GNUC_CHECK_VERSION(2, 4)`.
But `# define G_NORETURN __attribute__ ((__noreturn__))` was under
`#if G_GNUC_CHECK_VERSION(2, 8) || (0x5110 <= __SUNPRO_C)`.
Take the latter for `g_macro__has_attribute(__noreturn__)` fallback. This will
disable `G_GNUC_NORETURN` for GCC 2.4-2.7 though.
Fall back to compiler version checks only when `__has_attribute()` is not
available.
clang-cl doesn't define `__GNU__`, but still accepts attributes. This change
gets rid of a lot of warnings when building GLib with clang-cl. For GCC and
non-cl Clang nothing should change.
glib/gstring.c: In function ‘g_string_replace’:
glib/gstring.c:998:13: warning: comparison of integer expressions of different signedness: ‘gint’ {aka ‘int’} and ‘guint’ {aka ‘unsigned int’}
998 | if (n == limit)
| ^~
Calling g_atomic_ref_count_dec() or g_ref_count_dec() and the reference
count reaches zero results in different side effects depending on
whether the reference count is atomic or not.
The intended side effect when this happens is undefined, i.e. one should
not rely on the reference count actually reaching zero, or staying 1, or
becoming something else, and one should treat the grefcount /
gatomicrefcount to be unusable until reinitialized.
This wasn't documented, so add a paragraph about this.
This change is proposed by Kamil Dudka. It teaches Coverity to assume
that g_critical() will never return, which is desirable for the same
reasons it is for scan-build: once you've triggered undefined behavior,
the game is already lost, and there's limited benefit from trying to
avoid every possible memory leak on such codepaths. Notably, this
affects g_return_if_fail().
Arguably it might be desirable to fix every such issue, but if we're
already not doing so for scan-build, it doesn't make sense to hold
developers working with Coverity to a higher standard. This allows
focusing on more serious issues found by Coverity.
Thanks Kamil!
glib/gdate.c: In function ‘convert_twodigit_year’:
glib/gdate.c:1217:13: warning: comparison of integer expressions of
different signedness: ‘gint’ {aka ‘int’} and ‘guint’ {aka ‘unsigned int’}
1217 | if (y < two)
| ^
When using TAP we want every single line to be one of the following:
- a valid TAP clause
- a comment
- a blank line
Typical explicit test logs are single line comments, but in some cases
we might end up printing debug messages from libraries, and those may
contain multiple lines. When that happens, we break the TAP and fail the
test in conditions entirely outside of our control.
One option to avoid outright failure is to always prepend each line of a
messge with `#`, to ensure that the whole thing is considered a comment.
Resolve "g_date_time_format() does not return UTF-8 if LC_TIME is not UTF8 but other locale settings are UTF-8"
Closes#2055
See merge request GNOME/glib!1777
Use the GCC/Clang macros __has_extension() and __has_feature() on
c_static_assert, which is the documented way for GCC/CLang to check for
_Static_assert if C11 mode is not enabled, as suggested by Aleksandr Mezin.
As a result, add a private macro that is defined to be __has_extension if it
exists, otherwise it is considered to be always false.
It appears that CLang supports _Static_assert() even when not in C11
mode, since at least CLang 3.1, so let's just use that for CLang builds.
Fixes issue #2338.
Functions (_g_get_time_charset and _g_get_ctype_charset) to get LC_TIME and LC_CTYPE charset
by using nl_langinfo with _NL_TIME_CODESET and CODESET).
Another functions (_g_locale_time_to_utf8 and _g_locale_ctype_to_utf8) which uses thel and format
the input string accordingly.
Add new test cases with mixing UTF8 and non UTF8 LC_TIME along with UTF8
and non UTF8 LC_MESSAGES.
Closed#2055
Signed-off-by: Frederic Martinsons <frederic.martinsons@sigfox.com>
If the same `GKeyFile` is reused to load multiple different key files,
any loads after the first which encounter translated keys will crash,
because clearing the data from the first load cleared the cached
language names, but didn’t clear `checked_locales`, so they were never
reloaded.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2361
It should not be possible for `->locales` to be set without
`->checked_locales` being set, so drop the redundant check. This helps
with branch code coverage.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This is basically glnx_steal_fd() from libglnx. We already had two
private implementations of it in GLib.
Signed-off-by: Simon McVittie <smcv@collabora.com>
The (out caller-allocates) and (out callee-allocates) annotations are
meant for structured or pointer types. Plain old data types are just
regular out parameters and don't need the annotation about who
allocates them.
See: https://gitlab.gnome.org/GNOME/gjs/-/issues/386
In the 2.68 cycle we’d added 3 new enumerator elements. Due to the
preceding commit, they can now be annotated with
`GLIB_AVAILABLE_ENUMERATOR_IN_2_68`, which will make it a bit easier for
third party projects to notice when they’re using these symbols without
having bumped their GLib dependency.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2327
The changes in 4273c43902 did not guard
macros in `gatomic.h` which use `glib_typeof`. This meant that when
552b8fd862 was committed, moving the
include of `<type_traits>` under such a guard, these macros were still
trying to use it. This broke the build of at least vte.
Fix this by guarding the API break in `gatomic.h` too.
The doc used different phrasing for the same thing, e.g. "if any thread"
vs "any other thread."
Also make it clear that trying to take a write lock while already having
a lock, or trying to take a read lock while having a write lock, is
undefined.
When included inside an `extern "C"` block, this causes build failures
that look something like:
/usr/include/c++/10/type_traits:2930:3: error: template with C linkage
2930 | template<typename _Fn, typename... _Args>
| ^~~~~~~~
../../disas/arm-a64.cc:20:1: note: ‘extern "C"’ linkage started here
20 | extern "C" {
| ^~~~~~~~~~
Commit 4273c43902 made this opt in for
projects which are defining `GLIB_VERSION_MIN_REQUIRED`, but the include
of `<type_traits>` via `gmacros.h` was not included in this. If we move
the include out to the places where `glib_typeof` is called, we can make
it covered by this macro too, and save a few consumers from FTBFSing.
That also means that, if you don't want to fix your use of the headers,
and as long as this version is sufficient for you, a quick workaround is
to define `GLIB_VERSION_MIN_REQUIRED` to `GLIB_VERSION_2_66` or lower.
Suggested by Simon McVittie.
Alternative to: https://gitlab.gnome.org/GNOME/glib/-/merge_requests/1935
Fixes: https://gitlab.gnome.org/GNOME/glib/-/issues/2331
The `source_fds`/`target_fds` functionality is not supported on Windows
at the moment.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2097
This should introduce no functional changes, but condenses the variants
of the internal spawn implementation down to be more like `gspawn.c`.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2097
I realise Windows uses handles rather than PIDs, but given that there
are multiple platform-specific implementations of the public
`g_spawn_*()` API, I think it is less confusing for them all to use the
same naming scheme.
This introduces no functional changes.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This is a simple wrapper around the new source/target FD mapping
functionality in `fork_exec()`.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2097
If `stdout_fd` was set to (say) 6, and `stderr_fd` was set to 1, the
`set_cloexec()` call for setting up `stderr` would set the new `stdout`
for the forked process to be closed in the pending `exec()`.
This would cause the child process to error when writing to `stdout`.
This situation happens when using `G_SUBPROCESS_FLAGS_STDERR_MERGE`.
Add some conditions to prevent setting `CLOEXEC` in such cases.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2097
It was previously possible to specify the FD number which
`child_err_report_fd` was assigned, as a target FD in the FD mapping set
up using `g_subprocess_launcher_take_fd()`.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2097
This effectively moves some of the functionality of `GSubprocess`
(`g_subprocess_launcher_take_fd()`) into `g_spawn*()`, which should make
implementation a little simpler.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2097
This is an internal change which won’t affect the public API. It should
introduce no functional changes, but simplifies the code a little.
The arguments from `fork_exec_with_pipes()` have been added to
`fork_exec_with_fds()`. `child_close_fds` has been dropped since it’s
now an implementation detail within the function.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2097
Since !1715, g_atomic_pointer_get (&x) has usually returned the type of
x, rather than a generic pointer, in C++ code (where x is any pointer,
or any pointer-sized integer such as guintptr). glib/tests/cxx.cpp
asserts that this is the case.
However, this was only implemented for the lock-free fast-path, not
for the slow path used in platforms with an ARMv5 baseline (and
therefore no atomic instructions) such as Debian armel.
Signed-off-by: Simon McVittie <smcv@collabora.com>
GByteArray uses guint for storing the length of the byte array, but it
also has a constructor (g_byte_array_new_take) that takes length as a
gsize. gsize may be larger than guint (64 bits for gsize vs 32 bits
for guint). It is possible to call the function with a value greater
than G_MAXUINT, which will result in silent length truncation. This
may happen as a result of unreffing GBytes into GByteArray, so rather
be loud about it.
(Test case tweaked by Philip Withnall.)
This adds g_string_replace(), a function that replaces instances of one string
with another in a GString. It allows the caller to specify the maximum number
of replacements to perform, and returns the number of replacements performed
to the caller.
Fixes: #225
Unfortunately, `g_memdup()` accepts its size argument as a `guint`,
unlike most other functions which deal with memory sizes — they all use
`gsize`. `gsize` is 64 bits on 64-bit machines, while `guint` is only 32
bits. This can lead to a silent (with default compiler warnings)
truncation of the value provided by the caller. For large values, this
will result in the returned heap allocation being significantly smaller
than the caller expects, which will then lead to buffer overflow
reads/writes.
Any code using `g_memdup()` should immediately port to `g_memdup2()` and
check the pointer arithmetic around their call site to ensure there
aren’t other overflows.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2319
The public API `GIOChannel.line_term_len` is only a `guint`. Ensure that
nul-terminated strings passed to `g_io_channel_set_line_term()` can’t
exceed that length. Use `g_memdup2()` to avoid a warning (`g_memdup()`
is due to be deprecated), but not to avoid a bug, since it’s also
limited to `G_MAXUINT`.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2319
Convert all the call sites which use `g_memdup()`’s length argument
trivially (for example, by passing a `sizeof()` or an existing `gsize`
variable), so that they use `g_memdup2()` instead.
In almost all of these cases the use of `g_memdup()` would not have
caused problems, but it will soon be deprecated, so best port away from
it
In particular, this fixes an overflow within `g_bytes_new()`, identified
as GHSL-2021-045 by GHSL team member Kevin Backhouse.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: GHSL-2021-045
Helps: #2319
This will replace the existing `g_memdup()` function, which has an
unavoidable security flaw of taking its `byte_size` argument as a
`guint` rather than as a `gsize`. Most callers will expect it to be a
`gsize`, and may pass in large values which could silently be truncated,
resulting in an undersize allocation compared to what the caller
expects.
This could lead to a classic buffer overflow vulnerability for many
callers of `g_memdup()`.
`g_memdup2()`, in comparison, takes its `byte_size` as a `gsize`.
Spotted by Kevin Backhouse of GHSL.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: GHSL-2021-045
Helps: #2319
Various tests have leaks where it isn't clear whether the data is
intentionally not freed, or leaked due to a bug. If we mark these
tests as TODO, we can skip them under AddressSanitizer and get the
rest to pass, giving us a baseline from which to avoid regressions.
Signed-off-by: Simon McVittie <smcv@collabora.com>
AddressSanitizer detects memory leaks, NULL parameters where only a
non-NULL parameter is expected, and other suspicious behaviour, so if
we try to test that sort of thing we can expect it to fail.
Signed-off-by: Simon McVittie <smcv@collabora.com>
We preallocate buffers that are used after forked. That is because
malloc()/free() are not async-signal-safe and must not be used between
fork() and exec().
However, for the child process that exits without fork, valgrind wrongly
reports these buffers as leaked.
That can be suppressed with "--child-silent-after-fork=yes", but it is
cumbersome.
Work around by trying to allocate the buffers on the stack. At
least in the common cases where the pointers are small enough
so that we can reasonably do that.
If the buffers happen to be large, we still allocate them on the heap
and the problem still happens. Maybe we could have also allocated them
as thread_local, but currently glib doesn't use that.
[smcv: Cosmetic adjustments to address review comments from pwithnall]
For manual test coverage that would reproduce the bug fixed in !1902,
copy /bin/true (or any other harmless executable) to
/usr/bin/spawn-test-helper.
Signed-off-by: Simon McVittie <smcv@collabora.com>
do_exec() and g_execute() rely on being passed a NULL search path
if we intend to avoid searching the PATH, but since the refactoring
in commit 62ce66d4, this was never done. This resulted in some spawn
calls searching the PATH when it was not intended.
Spawn calls that go through the posix_spawn fast-path were unaffected.
The deprecated gtester utility, as used in GTK 3, relies on the
ability to run an executable from the current working directory by
omitting the G_SPAWN_SEARCH_PATH flag. This *mostly* worked, because
our fallback PATH ends with ".". However, if an executable of the
same name existed in /usr/bin or /bin, it would run that instead of the
intended test: in particular, GTK 3's build-time tests failed if
ImageMagick happens to be installed, because gtester would accidentally
run display(1) instead of testsuite/gdk/display.
Fixes: 62ce66d4 "gspawn: Don’t use getenv() in async-signal-safe context"
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977961
That changes the return type of functions like g_object_ref() that can
break C++ applications like Webkit. Note that it is not an ABI break.
It must thus be opt-in the same way we did when adding this to
g_object_ref() for GNU C compilers in the first place. Unfortunately it
cannot be done directly in gmacros.h because GLIB_VERSION_2_68 is not
defined there, and gversionmacros.h cannot be included there because
there is some strict ordering in which those headers must be included.
This means that applications that does not define
GLIB_VERSION_MIN_REQUIRED will still get an API break, so we encourage
them to declare their minimum requirement to avoir such issues in the
future too.
clang++ checks the 2nd args of __atomic_compare_exchange_n() has the
same type as the first, which fails when 2nd arg is nullptr which is of
type nullptr_t.
Ideally it should do `glib_typeof (*(atomic)) gapcae_oldval = (oldval);`
to ensure oldval and atomic have compatible types but unfortunately that
does not work neither.
Since that function never has been typesafe, and it is not even
attempting to use glib_typeof in case __ATOMIC_SEQ_CST is not defined,
drop it in __atomic_ case too.
Fixes issue #2226.
There are various places glib uses __typeof__ for type safety, but
that's a GNUC extension. C++11 has standard decltype() that does a
similar job, at least for cases we care about.
This avoids C++ code to always have to cast return value of
g_object_ref() which was causing type kind of error:
error: invalid conversion from ‘gpointer’ {aka ‘void*’} to
‘GstElementFactory*’ {aka ‘_GstElementFactory*’} [-fpermissive]
I found myself wanting to know the test that is currently being run,
where e.g. __func__ would be inconvenient to use, because e.g. the place
the string was needed was not in the test case function. Using __func__
also relies on the test function itself containing the whole path, while
loosing the "/" information that is part of the test path.
Since Windows 10 1607, we can make use of SetThreadDescription() API
for setting thread name. Unlike previously used exception based
method, this API will preserve configured thread name on dump file.
This makes it a little easier to link to in the generated documentation,
and separates it from the section above.
Link to the heading from the documentation for
`G_DEFINE_EXTENDED_ERROR`.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
On FreeBSD it always crashes due to the platform’s `vasprintf()`
implementation being less forgiving than Linux’s. That’s fine.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This is mostly to cover historic code, but also includes a couple of
additional tests for extended error domains (see #14).
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
At this point, if `dest` is non-`NULL` then we can guarantee
`*dest != NULL` due to `g_propagate_error()` succeeding.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
When loading a GKeyFile, the sequence is usually:
keyfile = g_key_file_new();
g_key_file_load_xxx(keyfile, ...)
g_key_file_new() calls g_key_file_init(), which allocates a parse_buffer
for parsing. g_key_file_load_xxx() will then g_key_file_clear() the
keyfile and call g_key_file_init() again.
Just don't allocate a parse_buffer unless we need it for parsing.
If no pointer to a GError* has been passed to public API, there's not
need to look at translations via gettext or format an error message that
g_set_error_literal will entirely ignore in the end.
Factor out the GError creation to a common function. When adding a
support for extended error types, this will limit the number of places
where these errors are allocated.
Realistically any date over 200 bytes long is not going to be valid, so
limit the input length so we can’t spend too long doing UTF-8 validation
or normalisation.
oss-fuzz#28718
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
On heavily loaded CI machines it seems to be taking about 1.3s between
one `g_get_monotonic_time()` call and the next. Allow that.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Occasionally this test fails in CI with the message:
```
assertion failed: (current_time / 1000000 - last_time / 1000000 == 1)
```
The way this calculation is done at the moment, a difference of 1001ms
between `current_time` and `last_time` can result in failure, if the
times are close to a multiple to 1000ms.
Change it to only truncate the result after doing the subtraction, and
add a 500ms tolerance to account for scheduling delays in the test. (For
example, the `test_func()` could be called, then descheduled before it
gets to call `g_get_monotonic_time()`.
Additionally, change the test to use `g_assert_cmpint()` so that future
failures provide more useful debug information.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Instead, return `NULL` if the checksum type is unsupported. This may
come in useful if we have to withdraw support for a particular checksum
type in future, due to it being broken.
These semantics were already in place for the return value of
`g_checksum_new()` — see commit 877cc60f and bug
comment https://bugzilla.gnome.org/show_bug.cgi?id=501853#c6.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This commit only looks at the `Returns:` lines in the documentation, and
has examined all of them in the file. Function arguments have not been
checked.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2227
This commit only looks at the `Returns:` lines in the documentation, and
has examined all of them in the file. Function arguments have not been
checked.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2227
This commit only looks at the `Returns:` lines in the documentation, and
has examined all of them in the file. Function arguments have not been
checked.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2227
This commit only looks at the `Returns:` lines in the documentation, and
has examined all of them in the file. Function arguments have not been
checked.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2227
Both are provided by libm, but `isnan()` is provided as a macro, whereas
`isfinite()` is an actual function, and hence libm has to be available
at runtime. That didn’t trivially work on FreeBSD, resulting in this
refactor.
`isfinite(x)` is equivalent to `!isnan(x) && !isinfinite(x)`. The case
of `x` being (negative or positive) infinity is already handled by the
range checks on the next line, so it’s safe to switch to `isnan()` here.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Rather than parsing the seconds in an ISO 8601 date/time using a pair of
floating point numbers (numerator and denominator), use two integers
instead. This avoids issues around floating point precision, and also
makes it easier to check for potential overflow from overlong inputs.
This last point means that the `isfinite()` check can be removed, as it
was covering the case where a NAN was generated, which isn’t now
possible using integer arithmetic.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
The fiendish thing about NAN is that it never compares TRUE against
anything, so the limit checks `seconds < 0.0 || seconds >= 60.0` were
never triggering.
oss-fuzz#28473
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
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 `nameprep()` function in `ghostutils.c` is quite complex, and does a
lot of allocations. This means it can take a long time on long hostnames
(on the order of 10KB long). Hostnames should never be that long,
though, so impose some loose length limits.
oss-fuzz#27371
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
It’s possible that GLib will eventually be compiled against a version of
libc which supports `close_range()` (hence `HAVE_CLOSE_RANGE` will be
defined), but then run against an older kernel which doesn’t support it.
In this case, we want to fall back to `fdwalk()`, which should work on
such systems.
This is what cpython does: 3529718925/Python/fileutils.c (L2227)
Spotted by Allison Karlitskaya in !1688.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
They extend the behavior of, respectively, -p and -s options of the
glib test framework
Currently test suite are only run for one level under -p path, for
example, testfilemonitor -p /monitor would execute the following tests:
/monitor/atomic-replace
/monitor/file-changes
/monitor/dir-monitor
/monitor/dir-not-existent
/monitor/cross-dir-moves
With the --run-prefix the sub-test suite file will be executed:
/monitor/atomic-replace
/monitor/file-changes
/monitor/dir-monitor
/monitor/dir-not-existent
/monitor/cross-dir-moves
/monitor/file/hard-links
The --skip-prefix and run-prefix seems symmetrical, but there is a
difference with skip towards run:
--skip-prefix will use a prefix while --run-prefix only work for a valid test path.
For example and for the following test family:
/monitor/atomic-replace
/monitor/file-changes
/monitor/dir-monitor
/monitor/dir-not-existent
/monitor/cross-dir-moves
/monitor/file/hard-links
while --run-prefix /mon will not execute anything, --skip-prefix /mon
will skip all of these tests.
See #2238 which references this change.
- Add a test for parsing FILE scheme from uri
It had taken from GST test_protocol_case
- Add a split uri test with encoded spaces in its path
It had taken from GST test_uri_get_location
- Add tests for g_uri_is_valid
It had taken from GST test_uri_misc
Note that the 4 followings uri failed under gst_uri_is_valid but not
under g_uri_is_valid
B:\\foo.txt
B:/foo.txt
B://foo.txt
B:foo.txt
- Add tests for g_uri_split
It had taken from GST test_url_parsing
- Add tests for test_uri_normalize and test_uri_parsing_relative
The test URI had been taken from GST test_url_normalization
- Add tests for test_uri_iter_params
It had taken from GST test_url_unescape_equals_in_http_query
Closes#2150
Signed-off-by: Frederic Martinsons <frederic.martinsons@sigfox.com>
It still works, and deprecating it would be quite disruptive (as it’s
used in headers), so amend the documentation to point people to
`G_NORETURN` instead.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #994
For URIs produced in string form, the path should be normalized and port
omitted when the default one is used. When querying the path and port of
a GUri (using getters or g_uri_split()) the normalized path and the
default port should be returned when they were omitted in the parsed URI.
Closes#2257
`g_time_zone_new_identifier()` returns NULL in the FreeBSD test setup,
presumably because `TZ` isn’t set.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #553
Use `g_time_zone_new_identifier()` instead so you can get error
checking.
Adapt the tests to match.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #553
In the Windows destructor list, consistently access
`g_private_destructors` using atomic primitives.
`g_atomic_pointer_compare_and_exchange()` should be equivalent to
`InterlockedCompareExchangePointer()`, but is a bit more understandable
in a general GLib context, and pairs with `g_atomic_pointer_get()`. (I
can’t find a Windows API equivalent for that.)
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #600
`volatile` should not be used to indicate atomic variables, and we
shouldn’t encourage its use. Keep the tests, since they check that we
don’t emit warnings when built against incorrect old code which uses
`volatile`. But add a comment to stop copy/paste use of `volatile`
in the future.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #600
This is technically an API break, but since the type is meant to be
opaque (third party code is not meant to treat it like an integer) it
should not cause problems.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #600
These variables were already (correctly) accessed atomically. The
`volatile` qualifier doesn’t help with that.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #600
It’s not necessary and provides no thread safety guarantees.
The `volatile` qualifiers on the function arguments have to be kept, as
they are (unfortunately) part of the API.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #600
It’s not necessary and provides no thread safety guarantees.
The `volatile` qualifiers on the function arguments have to be kept, as
they are (unfortunately) part of the API.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #600
These variables were already (correctly) accessed atomically. The
`volatile` qualifier doesn’t help with that.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #600
And drop the `volatile` qualifier from the variable, as that doesn’t
help with thread safety.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #600
And drop the `volatile` qualifier from the variable, as that doesn’t
help with thread safety.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #600
Add a new variant of `g_time_zone_new()` which returns `NULL` on
failure to load a timezone, rather than silently returning UTC.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #553
In file included from glib/glib.h:86,
from glib/tests/uri.c:25:
glib/gtestutils.h:134:96: error: comparison of integer expressions of different signedness: ‘gint’ {aka ‘int’} and ‘GConvertError’
134 | if (!err || (err)->domain != dom || (err)->code != c) \
| ^~
glib/tests/uri.c:182:9: note: in expansion of macro ‘g_assert_error’
182 | g_assert_error (error, G_CONVERT_ERROR, file_to_uri_tests[i].expected_error);
| ^~~~~~~~~~~~~~
glib/gtestutils.h:134:96: error: comparison of integer expressions of different signedness: ‘gint’ {aka ‘int’} and ‘GConvertError’
134 | if (!err || (err)->domain != dom || (err)->code != c) \
| ^~
glib/tests/uri.c:220:9: note: in expansion of macro ‘g_assert_error’
220 | g_assert_error (error, G_CONVERT_ERROR, file_from_uri_tests[i].expected_error);
| ^~~~~~~~~~~~~~
glib/tests/uri.c: In function ‘test_uri_parsing_absolute’:
glib/gtestutils.h:134:96: error: comparison of integer expressions of different signedness: ‘gint’ {aka ‘int’} and ‘GUriError’
134 | if (!err || (err)->domain != dom || (err)->code != c) \
| ^~
glib/tests/uri.c:790:11: note: in expansion of macro ‘g_assert_error’
790 | g_assert_error (error, G_URI_ERROR, test->expected_error_code);
| ^~~~~~~~~~~~~~
In file included from glib/glibconfig.h:9,
from glib/gtypes.h:32,
from glib/galloca.h:32,
from glib/glib.h:30,
from glib/tests/uri.c:25:
glib/tests/uri.c: In function ‘test_uri_iter_params’:
glib/tests/uri.c:1495:51: error: comparison of integer expressions of different signedness: ‘gssize’ {aka ‘const long int’} and ‘long unsigned int’
1495 | params_tests[i].expected_n_params <= G_N_ELEMENTS (params_tests[i].expected_param_key_values) / 2);
| ^~
glib/gmacros.h:941:25: note: in definition of macro ‘G_LIKELY’
941 | #define G_LIKELY(expr) (expr)
| ^~~~
glib/tests/uri.c:1494:7: note: in expansion of macro ‘g_assert’
1494 | g_assert (params_tests[i].expected_n_params < 0 ||
| ^~~~~~~~
glib/tests/uri.c: In function ‘test_uri_parse_params’:
glib/tests/uri.c:1562:51: error: comparison of integer expressions of different signedness: ‘gssize’ {aka ‘const long int’} and ‘long unsigned int’
1562 | params_tests[i].expected_n_params <= G_N_ELEMENTS (params_tests[i].expected_param_key_values) / 2);
| ^~
glib/gmacros.h:941:25: note: in definition of macro ‘G_LIKELY’
941 | #define G_LIKELY(expr) (expr)
| ^~~~
glib/tests/uri.c:1561:7: note: in expansion of macro ‘g_assert’
1561 | g_assert (params_tests[i].expected_n_params < 0 ||
| ^~~~~~~~
glib/tests/uri.c: In function ‘run_file_to_uri_tests’:
glib/tests/uri.c:172:17: error: comparison of integer expressions of different signedness: ‘int’ and ‘long unsigned int’
172 | for (i = 0; i < G_N_ELEMENTS (file_to_uri_tests); i++)
| ^
glib/tests/uri.c: In function ‘run_file_from_uri_tests’:
glib/tests/uri.c:197:17: error: comparison of integer expressions of different signedness: ‘int’ and ‘long unsigned int’
197 | for (i = 0; i < G_N_ELEMENTS (file_from_uri_tests); i++)
| ^
glib/tests/uri.c: In function ‘run_file_roundtrip_tests’:
glib/tests/uri.c:276:17: error: comparison of integer expressions of different signedness: ‘int’ and ‘long unsigned int’
276 | for (i = 0; i < G_N_ELEMENTS (file_to_uri_tests); i++)
| ^
glib/tests/uri.c: In function ‘test_uri_parse_params’:
glib/tests/uri.c:1594:25: error: comparison of integer expressions of different signedness: ‘gsize’ {aka ‘long unsigned int’} and ‘gssize’ {aka ‘const long int’}
1594 | for (j = 0; j < params_tests[i].expected_n_params; j += 2)
| ^
glib/tests/timer.c: In function ‘test_timeval_from_iso8601’:
glib/tests/timer.c:220:17: error: comparison of integer expressions of different signedness: ‘gint’ {aka ‘int’} and ‘long unsigned int’
220 | for (i = 0; i < G_N_ELEMENTS (tests); i++)
| ^
glib/tests/timer.c: In function ‘test_timeval_to_iso8601’:
glib/tests/timer.c:260:17: error: comparison of integer expressions of different signedness: ‘gint’ {aka ‘int’} and ‘long unsigned int’
260 | for (i = 0; i < G_N_ELEMENTS (tests); i++)
| ^
This commit is the unmodified results of running
```
black $(git ls-files '*.py')
```
with black version 19.10b0. See #2046.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
glib/tests/shell.c: In function ‘main’:
glib/tests/shell.c:194:17: error: comparison of integer expressions of different signedness: ‘gint’ {aka ‘int’} and ‘long unsigned int’
194 | for (i = 0; i < G_N_ELEMENTS (cmdline_tests); i++)
| ^
glib/tests/shell.c:201:17: error: comparison of integer expressions of different signedness: ‘gint’ {aka ‘int’} and ‘long unsigned int’
201 | for (i = 0; i < G_N_ELEMENTS (quote_tests); i++)
| ^
glib/tests/shell.c:208:17: error: comparison of integer expressions of different signedness: ‘gint’ {aka ‘int’} and ‘long unsigned int’
208 | for (i = 0; i < G_N_ELEMENTS (unquote_tests); i++)
| ^
glib/tests/slice.c: In function ‘test_allocate’:
glib/tests/slice.c:146:17: error: comparison of integer expressions of different signedness: ‘gint’ {aka ‘int’} and ‘long unsigned int’
146 | for (i = 0; i < G_N_ELEMENTS(threads); i++)
| ^
glib/tests/slice.c:149:17: error: comparison of integer expressions of different signedness: ‘gint’ {aka ‘int’} and ‘long unsigned int’
149 | for (i = 0; i < G_N_ELEMENTS(threads); i++)
| ^
glib/tests/spawn-singlethread.c: In function ‘test_spawn_async_with_fds’:
glib/tests/spawn-singlethread.c:204:17: error: comparison of integer expressions of different signedness: ‘int’ and ‘long unsigned int’
204 | for (i = 0; i < G_N_ELEMENTS (tests); i++)
| ^
glib/guri.c: In function ‘should_normalize_empty_path’:
glib/guri.c:756:17: error: comparison of integer expressions of different signedness: ‘int’ and ‘long unsigned int’
756 | for (i = 0; i < G_N_ELEMENTS (schemes); ++i)
| ^
