I believe the specification was originally a shorter extract of
Allison’s thesis. This left a few dangling references to requirements
which were listed in a part of the thesis not included in the
specification.
Reword them slightly so they’re not quite so awkward.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
The licensing for the original GVariant specification was not specified
in the original PDF.
However, CC-BY-SA-3.0 has been agreed by Allison, the sole copyright
holder, here:
https://gitlab.gnome.org/Teams/documentation/developer-www/-/merge_requests/108/#note_1586866
The diagrams were redrawn by me, so their licensing/copyright status is
clear.
Tested with `reuse lint` to ensure the data is machine-readable.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
That’s what xdgmime uses for zero-sized files (see `XDG_MIME_TYPE_EMPTY`).
Historically, GLib explicitly used `text/plain` for empty files, to
ensure they would open in a text editor. But `text/plain` is not really
correct for an empty file: the content isn’t text because there is no
content. The file could eventually become something else when written
to.
Text editors which want to be opened for new, empty files should add
`application/x-zerosize` to their list of supported content types.
Users who want to set a handler for `application/x-zerosize` on their
desktop should use
```sh
gio mime application/x-zerosize # to see the current handler
gio mime application/x-zerosize org.gnome.gedit.desktop # to set it
```
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2777
`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.
