Further to commit bcd364afef, fix the types accepted by the
`g_str_equal()` macro for C++ too. C++ is more restrictive about
const-correctness.
Add unit tests.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2820
This reverts commit 7e3e591d43.
The freedesktop SDK, which is used by gnome-build-meta, only has Meson
0.63. Bumping GLib’s Meson dependency to 0.64 means that, at the moment,
GLib is not buildable in gnome-build-meta and hence can’t be tested in
nightly pipelines against other projects, etc.
That’s bad for testing GLib.
It’s arguably bad that we’re restricted to using an older version of
Meson than shipped by Debian Testing, but that’s a separate discussion
to be had.
Revert the Meson 0.64 dependency until the freedesktop SDK ships Meson ≥
0.64. This also means reverting the simplifications to use of
`gnome.mkenum_simple()`.
See https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3077#note_1601064
This is deprecated since Meson 0.62.0, since Meson does this
automatically for us.
This fixes a Meson configure warning.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
They were mixing up `(optional)` and `(nullable)`, and didn’t correctly
annotate the arguments as `(inout)` or `(transfer full)`.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2793
We need to ensure that all the expected macros and utilities are working
with all the supported C standards, so just repeat the tests with all
the ones the compiler supports.
We defined G_NO_RETURN as [[noreturn]] in the C++ case, but only after
trying the __attribute__ syntax, so it was never used in GNUC compatible
compilers.
Give it priority instead when supporting a C++11 compiler and onwards.
As per this we need to adapt the code in the places where it was not
properly used (leading to compilation warnings).
Since it’s now always called the same way after safe_fdwalk() has been
called. This introduces no functional changes.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This thread is created once during the process’ lifetime and cannot be
destroyed and recreated, as the thread scheduler settings might have
changed since then.
Mark the leak as explicit, mostly for documentation purposes — but it
might quieten some static analysers.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Coverity CID: #1474614
In `safe_closefrom()`, we thought it would be OK to assert that an FD
being closed is valid, when using `safe_fdwalk()`, as it only walks over
known-valid FDs.
However, there is a situation where that might not be true: the program
is being run under valgrind. Valgrind opens some FDs for its own use
which are ≥1024, and it emulates a lowered soft limit on FDs. So if we
were to use `safe_fdwalk_with_invalid_fds()` it would see the lowered
soft limit and not try to close valgrind’s internal FDs.
However, `safe_fdwalk()` looks at `/proc`, which valgrind does not emulate,
so it sees the secret valgrind internal FDs, and then tries to close them.
Valgrind doesn’t like this, prints ‘Warning: invalid file descriptor
1024 in syscall close()’ and returns `EBADF`. That return value
causes `g_close()` to warn about faulty FD refcounting, and that causes
unit test failures.
Fix that by relaxing our assumptions about FD validity: use
the `close_func_with_invalid_fds()` call back for closing FDs
from `safe_fdwalk()`, rather than using `close_func()`. That will
ignore `EBADF` return values.
This should fix valgrind failures like this one:
https://gitlab.gnome.org/GNOME/glib/-/jobs/2389977
Related prior art: https://bugs.freedesktop.org/show_bug.cgi?id=99839
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
The new macro form of `g_str_equal()` had stricter type checking than
the original function form. That would be nice, except it causes new
compiler warnings in third party projects, which counts as an API break
for us, so unfortunately we can’t do it.
Add some tests to prevent regressions on this again.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2809
Sadly, in C++ there's not an universal way to get what language standard
is used to compile GLib-based programs, in fact while most compilers
relies on `__cplusplus`, MSVC is defining that, but it does not use it
to expose such information (unless `/Zc:__cplusplus` arg is used).
On the other side, MSVC reports the language standard via _MSVC_LANG [1].
This complication makes us defining some macros in a very complex way
(such as glib_typeof()), because we need to perform many checks just to
understand if a C++ compiler is used and what standard is expecting.
To avoid this, define multiple macros that can be used to figure out
what C++ standard is being used.
[1] https://docs.microsoft.com/en-us/cpp/build/reference/zc-cplusplus?view=msvc-170
This should quell a scan-build error about dereferencing `member_info`
when it’s `NULL` at the end of the function, due to having zero
iterations of the `for` loop.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This should quell some scan-build warnings about code breaking after
returning from mem_error() in a weird state.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Do not use can_run_host_binaries() as it returns true even though
custom_target() does not currently correctly wrap target-built
tool binaries with exe_wrapper so they can be run on the host.
See https://github.com/mesonbuild/meson/issues/11029
This further helps with the potential denial of service problem in
issue #2782 / oss-fuzz#49462 / oss-fuzz#20177.
Instead of allocating a new `GVariant` for each nesting level of
maybe-types, allocate a single `GVariant` and give it the fully-nested
maybe type as its type. This has to be done in serialised form.
This prevents attackers from triggering O(size of container × typedecl
depth) allocations.
This is a follow up to commit 3e313438f1,
and includes a test.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2782
oss-fuzz#20177
oss-fuzz#49462
This reverts commit 476e33c3f3.
We’ve decided to remove `G_OS_DARWIN` in favour of recommending people
use `__APPLE__` instead. As per the discussion on #2802 and linked
issues,
* Adding a new define shifts the complexity from “which of these
platform-provided defines do I use” to “which platform-provided
defines does G_OS_DARWIN use”
* There should ideally be no cases where a user of GLib has to use
their own platform-specific code, since GLib should be providing
appropriate abstractions
* Providing a single `G_OS_DARWIN` to cover all Apple products (macOS
and iOS) hides the complexity of what the user is actually testing:
are they testing for the Mach kernel, the Carbon and/or Cocoa user
space toolkits, macOS vs iOS vs tvOS, etc
Helps: #2802
g_str_has_prefix uses G_UNLIKELY itself, and up
until recently, G_UNLIKELY could not be nested.
This commit adds a test that nests G_UNLIKELY to
make sure it continues to work going forward.
This avoids a -Wshadow warning when nesting G_LIKELY() inside
each other due to _g_boolean_var_.
This can be easily encountered when using macros:
```
#define GET_VALUE(arg) \
({ \
typeof (arg) _arg = (arg); \
\
g_assert (_arg); \
get_value (_arg); \
})
g_assert (GET_VALUE (a) > 5);
```
__COUNTER__ is a GCC extension, but the definition of _G_BOOLEAN_EXPR()
is already inside a
#if defined(__GNUC__) && (__GNUC__ > 2) && defined(__OPTIMIZE__)
block.
Closes: #1211
We thought we could drop the x + !x workaround in
commit eea87eff3f but apparently
not.
This commit adds it back, but with an added layer of indirection,
for aesthetics.
Closes: #2807
This is basically !3036, but wasn't included there because !3036
and !3027 were developed in parallel.
Signed-off-by: Simon McVittie <smcv@collabora.com>
g_clear_fd wraps g_close and is async-signal-safe under essentially the
same circumstances. If fd_ptr already pointed to a negative number, then
g_clear_fd doesn't call g_close, and is still async-signal-safe.
g_autofd passes a NULL error pointer to g_clear_fd, so it is
async-signal-safe, as long as no programming error occurs.
Signed-off-by: Simon McVittie <smcv@collabora.com>
g_clear_fd has the same interaction with errno as g_close or most libc
functions: on success it has an unspecified effect on errno, and on
failure (other than programming error) it sets errno to indicate the
reason for failure.
Signed-off-by: Simon McVittie <smcv@collabora.com>
...when the test program aborts while checking the FD's were indeed
closed, since we need to override the invalid parameter handler to do
such checks, if the CRT demands so, so that the test program will
proceed normally.
This will fix issue #2800.
...if supported, as in the previous commit. We will eventually use
these private API to override the invalid parameter handler as needed
in the other parts of GLib and the tests.
We also now use _set_thread_local_invalid_parameter_handler()
instead of just _set_invalid_parameter_handler() to be safer, if
that is available.
This can be expanded upon in the future if we desire to use a stricter
or more customized invalid parameter handler.
Allow one to override the invalid parameter handler if we have the
following items:
* _set_invalid_parameter_hander() or
_set_thread_local_parameter_handler()
* _CrtSetReportMode() as a function or macro
Currently, we are doing this on Visual Studio to allow GSpawn to work on
Windows as well as having the log writer support color output, as we
might be passing in file descriptors that are invalid, which will cause
the CRT to abort unless the default invalid parameter handler is
overridden.
