It’s deprecated, but the big red 0/0/0 line for the `glib/gthread`
directory in the lcov output for GLib is driving me nuts.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
The fuzz tests are run on a separate CI system, and we don’t care what
their code coverage is. The only reason they’re run on our CI systems at
all is as a smokecheck. They are not unit tests that we want to check
are running every line.
Similarly, exclude copylibs/subprojects as GLib is not responsible for
testing them. They have (or should have) their own unit tests and code
coverage metrics in their upstreams.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This typically indicates a bug in the program, where a GTask has been
created, but a bug in the control flow has caused it to not return a
value.
There is one situation where it might be legitimate to finalise a GTask
without returning: if an error happens in your *_async() start function
after you’ve created a GTask, but before the async operation returns to
the main loop; and you report the error using g_task_report_*error()
rather than reporting it using the newly constructed GTask.
Another situation is where you are just using GTask as a convenient way
to move some work to another thread, without the complexity of creating
and running your own thread pool. GDBus does this with
g_dbus_interface_method_dispatch_helper(), for example.
In most other cases, it’s a bug. Emit a debug message about it, but not
a full-blown warning, as that would create noise in the legitimate
cases.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This can be used to mark entire types as deprecated,
and trigger a warning when they are instantiated
and `G_ENABLE_DIAGNOSTIC=1` is set in the environment.
There's currently no convenient macros for defining
types with the new flag, but you can do:
```c
_G_DEFINE_TYPE_EXTENDED_BEGIN (GtkAppChooserWidget,
gtk_app_chooser_widget,
GTK_TYPE_WIDGET,
G_TYPE_FLAG_DEPRECATED)
...
_G_DEFINE_TYPE_EXTENDED_END ()
```
Includes a unit test by Philip Withnall.
the gio dbus codegen test has 10 test cases in it.
Each test case is given 100 seconds to complete.
That is far longer than they should need.
Furthermore, the entire test is only given 60s
to complete.
This commit makes the internal timeout more consistent
with the external timeout, by giving each of the 10
test cases 6 seconds instead of 100s.
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 doesn’t enforce licensing/copyright headers to be present on all
files, but does check that at least a minimum number of files are
correct.
This should help avoid new files being added without appropriate
licensing information in future.
The baseline is set at what `reuse lint` outputs for me at the moment.
See https://reuse.software/tutorial/#step-2 for information about how to
add REUSE-compliant licensing/copyright to files.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1415
This will make it clear what the bigger changes are between versions.
Kind of like a `NEWS` file for the specification.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This should clarify object paths and signatures a little, if anyone
needs that. This introduces no semantic changes.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
reStructuredText doesn’t support cross-references unless always built
with Sphinx (as I understand it). `rst2html5` doesn‘t support them.
So reword this (currently manual) cross-reference so it’s less awkward.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
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
