It needs to be in a separate page because there isn’t actually a
`GFileAttribute` type.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
Helps: #3037
Move it to the struct docs, although again this is a little suspect
because there is actually no `GDBusAddress` struct/type.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
Helps: #3037
This might not work, as `GContentType` isn’t actually a defined type
(content types are just strings). It would be a bit weird to create a
separate page for content types, though, as the functions handling them
are very method-like and feel like they should be grouped together like
methods of a class.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
Helps: #3037
It needs to be in a separate page because it’s all macros and they have
no type/class associated with them.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
Helps: #3037
Gate the API reference on the availability of the introspection data as
well, so we don't accidentally try and generate the documentation
without a description of our API.
Currently, the introspection data for GLib and its sub-libraries is
generated by gobject-introspection, to avoid the cyclic dependency
between the two projects.
Since gobject-introspection is generally available on installed systems,
we can check for its presence, and generate the introspection data
directly from GLib.
This does introduce a cyclic dependency, which is why it's possible to
build GLib without introspection, then build gobject-introspection, and
finally rebuild GLib.
By having introspection data available during the GLib build, we can do
things like generating documentation; validating newly added API; and
close the loop between adding new API and it becoming available to non-C
consumers of the C ABI (i.e. language bindings).
If `update-desktop-database` or `update-mime-database` are not
installed, there are a few `GAppInfo` methods for modifying file
associations which will print a `g_warning()` when called. Something
like:
```
GLib-GIO-FATAL-WARNING: Failed to execute child process ‘update-desktop-database’ (No such file or directory)
```
(Example: https://gitlab.gnome.org/zamaudio/glib/-/jobs/3190053)
This will cause the appinfo/associations test to fail, as warnings are
fatal.
If that’s going to happen, skip the test. We can’t hard-depend on these
tools as they are external to GLib and only needed for a few operations.
Instead we have a soft runtime dependency on them; that should be
reflected in the tests.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
Helps: #3148
The alt-digits are loaded from `nl_langinfo()` in a `GOnce` section,
which means `nl_langinfo()` is not re-queried after the process changes
locale (if that happens).
So, change the `GOnce` to a mutex and store the locale of the alt-digits
alongside them. This will introduce contention when calling
`format_number()` is called, but how often are multiple threads trying
to format dates at the same time?
If this does get highlighted as a performance problem, the other
approach I considered was a `GPrivate` struct containing all the
locale-specific cached data. That comes at the cost of using a
`GPrivate` slot (although that’s only particularly expensive on Windows,
and the locale code is quite different for Windows, so perhaps that
could be avoided entirely). It does mean that all locale printing could
be lock-free and still safely update cached data on a locale change.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
When calling `g_file_set_contents_full()` without
`G_FILE_SET_CONTENTS_CONSISTENT`, the file is written by opening it,
`write()`ing to it, then closing it.
This is fine as long as the file is not longer than the new content you
want to set its contents to. If it is, the last bit of the old content
remains, because `g_file_set_contents_full()` was missing an
`ftruncate()` call.
Fix that, and change the tests to catch truncation failures in future.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #3144
