Move it to a separate page so the difference between `g_rand_*()` and
`g_random_*()` can be explained.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3037
It was one paragraph which mentioned `GHookList` and `GHook`, both of
which have their own adequate documentation sections.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3037
Move it to a separate page so more detail can be provided about all the
groups of API.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3037
Move it to a separate page so an overview of the deprecated threading
API can be given.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3037
The image uses `alpine:latest`, so let’s drop the ‘stable’ moniker. This
also makes the container registry ID match the Dockerfile name.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
My GTK testlogs are filled with
GLib-DEBUG: g_unix_open_pipe() called with FD_CLOEXEC; please migrate to using O_CLOEXEC instead
Lets take the hint, and migrate to using O_CLOEXEC.
As with `test-printf`, the `vasprintf()` placeholder checks on BSDs
(including macOS) are less strict than on Linux (glibc), so the expected
critical message is not seen.
Change the test to not expect it on BSDs.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3187
It was previously 4KiB, but this isn’t enough for sniffing the
content-type of some GPT disk images (they use 4KiB sectors, and the
magic bytes are in the second sector). A buffer of 8KiB would work,
but 16KiB seems harmless and more future proof.
Most of the time, the buffer size should be set by xdgmime anyway, based
on the largest sniff buffer its database needs. Currently (with
shared-mime-info master) that’s 18730 bytes, so even with a 16KiB buffer
we’re going to potentially mis-identify a few file types.
Tested manually by modifying the example GPT image from shared-mime-info
(https://gitlab.freedesktop.org/xdg/shared-mime-info/-/blob/master/tests/mime-detection/disk.gpt)
to remove the magic at offset 0x200 and add it instead at offset 0x1000,
then running:
```
cp shared-mime-info.git/tests/mime-detection/disk.gpt ./disk-without-extension
gio info -a standard::content-type ./disk-without-extension
```
It should print `application/vnd.efi.img` rather than
`application/octet-stream`.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3186
It was previously possible for this to silently fail, which isn’t great
for program correctness. Instead, raise a critical warning so the
programmer knows to either validate their Unicode inputs, or fix their
format placeholders.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3187
It’s possible for the function to fail for the same reasons
`g_vasprintf()` would fail.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3187
As per the previous commit, it’s possible for
`g_printf_string_upper_bound()` to return an error. We need to catch and
handle that error in `g_vasprintf()` to avoid it trying to write to a
`NULL` string allocation and crashing.
So, call `g_vsnprintf()` directly instead of calling
`g_printf_string_upper_bound()`, so that the error case can be handled.
There was already a test for some of this behaviour
(`test_vasprintf_invalid_format_placeholder()`). Because it tested an
invalid format string, the `_g_vsprintf()` call bailed out before
checking whether the buffer it had been passed was `NULL`. The new test
has a valid format string, but an invalid arg.
When running the tests locally, I have disabled the `USE_SYSTEM_PRINTF`
and `HAVE_VASPRINTF` code paths in `g_vasprintf()`.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3187
Spotted in https://gitlab.gnome.org/GNOME/glib/-/issues/3187.
In an ideal world, this API would have been designed with an error
return path to begin with — perhaps by returning a `GError` or a
`gssize`. We can’t change the API now, though, which leads to this
slightly awkward “0 indicates an error or success” pattern.
I think that’s justified in this case because:
- This API does not see much use.
- Format strings tend to be literals, and almost always are
non-zero-length, so it tends to be statically possible to determine
that the function won’t return zero on success.
- If callers do need to differentiate the two zero return value cases,
they can just call `g_vsnprintf()` directly instead.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3187
The test needs to call `ftruncate64()` (not `ftruncate()`) to guarantee
it’s using the 64-bit version on Linux, but this doesn’t exist on other
platforms.
Test to see if it exists and, if not, skip the test.
Fixes commit cf5e371c67, and fixes CI
failures like https://gitlab.gnome.org/GNOME/glib/-/pipelines/602930.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
The win32-specific APIs in GLib are only defined when building for
Windows. Unfortunately, this means they can not show up in `GLib-2.0.gir`
if it’s build on Linux (which is what mostly happens).
Consequently, that means they’re not present in the API documentation,
which is a bit of a problem.
Make the symbols in the header available on other platforms
(particularly Linux) if building with `g-ir-scanner` (but not
otherwise). This means the win32 symbols show up in `GLib-2.0.gir` and
hence in the documentation.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3037
On certain platforms where file size (off_t) can be truncated when assigning to
gsize, get_contents_regfile() may use the truncated size as the size to read. Add
an explicit check to raise an error in such cases.
G_FILE_ERROR_FAILED will be raised in this case, aligning with behavior for other
cases.
This generally affects 32-bit non-Win32 platforms.
Just as they were ignored under gtk-doc, ignore them when scanning the
sources using `g-ir-scanner`, and make it look at the full function
declarations instead.
This fixes inclusion of functions like `g_creat()` in the documentation.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3037
This allows the methods for `GDir` to be introspected. While we don’t
expect languages which use the introspection bindings to use `GDir`,
full introspection support is necessary for the `GDir` documentation to
be correctly built with gi-docgen.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3037
All GLib tests normally respect `TMPDIR` for writing their temporary
files to. The utils test, however, contained a hack which overwrote
`TMPDIR` so that it could test the behaviour of `g_get_tmp_dir()` for
regressions.
Unfortunately, that hack affected the whole `utils` test suite, not just
the one regression test.
Use the new `g_test_trap_subprocess_with_envp()` API to allow the
regression test to be run as a subprocess with its environment modified,
which allows us to remove the hack affecting the rest of the test suite.
Spotted in
https://gitlab.gnome.org/GNOME/glib/-/issues/3179#note_1925161.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
This is a variant of `g_test_trap_subprocess()` which allows the
environment for the child process to be specified. This is quite useful
when you want to test code which reads environment variables, as it’s
not safe to set those after the start of `main()`.
This will be useful within and outwith GLib for testing such code.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #1618
The problem is that resetting the environment of a
proccess is not safe, this is mentioned in the man
pages of the setenv, and also by the concept:
when we get a constant string returned by the getenv,
we need to be guaranteed that this string will exist
during all that time we are using it. While setting
the same env var to another value destroys this string
inside of libc.
Now looking at the should_drop_message(), we can see
that it just gets the environment on every call. Getting
the environment is safe, but however there's no safe way
to switch the logging domains selection: setenv can't be
used because of the reasons listed above.
That is why g_log_writer_default_set_debug_domains() is
needed: it's just a safe replacement for the setenv in this case.
Now should_drop_message() still reads the environment, but
does so only on the first call, after that the domains are
stored internally, and can only be changed by
g_log_writer_default_set_debug_domains().
This also means that now resetting G_MESSAGES_DEBUG env
var in runtime has no effect. But in any case this is not
what the user should do, because resetting the environment
in runtime is not correct.
They were still failing with `-Dglib_assert=false` because
`G_DISABLE_ASSERT` wasn’t being explicitly un-defined for the test.
See https://gitlab.gnome.org/GNOME/glib/-/jobs/3309889
Also while we’re there, take the opportunity to correctly set the test
suite, protocol and environment.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
