`HAVE_COCOA` should be used only in the places where we’re actually
depending on the Cocoa toolkit. It should not be used as a general way
of detecting building on a Darwin-based OS such as macOS.
Conversely, there are a few places in the code where we do want to
specifically detect the Cocoa toolkit (and others where we specifically
want to detect Carbon), so keep `HAVE_COCOA` and `HAVE_CARBON` around.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2802
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
-Wnonnull is sort of fickle and it's an option a lot of consumers
of glib use.
This commit makes sure it gets used on linux during CI as well, so
we can catch compat problems before they hit our users.
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>
The GitLab instance has been moved around, so the SSH clone URI for
repositories has changed. Change that in `CONTRIBUTING.md`, and also
change to using a relative path in `.gitmodules` to insulate from
similar URI changes in future.
Changing to a relative path in `.gitmodules` also enables the CI to use
submodules more easily: https://docs.gitlab.com/ee/ci/git_submodules.html
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
To better reflect its purpose.
This will also help distinguish it from a job being added in a following
commit.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
...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.
Some platforms (e.g., macOS) don't currently have a way
to close only open fds in preparation for exec. On these
platforms, glib just bites the bullet and calls g_close for
the whole fileno range.
g_close only allows valid fds to be given to it, though.
This commit ensures close is called instead of g_close on
those platforms by splitting the safe_fdwalk implementation
that operates on invalid fds off to its own function and
only using it as a fall back.
It's possible when gspawn sets up its pipes for standard io,
that the pipe fds themselves end up in the standard io range
reserved for stdin, stdout, stderr.
This commit protects against that problem by relocating the
fds up, outside of the range.
Closes: #16
The error code is already used for both F_DUPFD and dup2
already, and having dup2 in the name is oddly specific.
This renames the error code for clarity.
Now that we know it's a bad idea to avoid the standard io fd range
when getting pipe fds for g_unix_open_pipe, we should test to make sure
we don't inadvertently try to do it again.
This commit adds that test.
g_unix_open_pipe tries to avoid the standard io fd range
when getting pipe fds. This turns out to be a bad idea because
certain buggy programs rely on it using that range.
This reverts commit d9ba615090Closes: #2795Reopens: #16
The SPDX-License-Identifier said LGPL-2.1-or-later, but the license
grant was a permissive license, which we now identify as
LicenseRef-old-glib-tests.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Some of GLib's unit tests are under an apparently GLib-specific
permissive license, vaguely similar to the BSD/MIT family but with the
GPL's lack-of-warranty wording. This is not on SPDX's list of
well-known licenses, so we need to use a custom license name prefixed
with LicenseRef if we want to represent this in SPDX/REUSE syntax.
Most of the newer tests seem to be licensed under LGPL-2.1-or-later
instead.
Signed-off-by: Simon McVittie <smcv@collabora.com>
In g_proxy_resolver_lookup_async() we have some error validation that
detects invalid URIs and directly returns an error, bypassing the
interface's lookup_async() function. This is great, but when the
interface's lookup_finish() function gets called later, it may assert
that the source tag of the GTask matches the interface's lookup_async()
function, which will not be the case.
As suggested by Philip, we need to check for this situation in
g_proxy_resolver_lookup_finish() and avoid calling into the interface
here if we did the same in g_proxy_resolver_lookup_async(). This can be
done by checking the source tag.
I added a few new tests to check the invalid URI "asdf" used in the
issue report. The final case, using async GProxyResolver directly,
checks for this bug.
Fixes#2799
