This way, the generated GResource code won't choke if no prototypes are found
when being built by clang-cl, which also goes the _MSC_VER >= 1500 route.
Fixes clang-cl build of generated GResources code when building the appstream
git checkout, which supported Windows recently, as the build there demands
'-Werror,-Wmissing-prototypes'.
Part-of: <https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3589>
With gcc and clang using -Wsign-conversion a related warning is generated
if code using glib 2.78.0 contains function g_assert_cmpint().
Warning is fixed by adding related casts. Related tests have been also
updated and will be also compiled with -Wsign-conversion to detect
related problems in future.
The pointer argument must not be `NULL` (though it can point to a
location which is zero/null-valued), so this should be `(not optional)`
not `(not nullable)`.
Spotted in !3577.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
On FreeBSD /home is generally a symlink to /usr/home, so the relative
resolves to /usr/bin instead of /bin and `sh` can only be found in /bin
on FreeBSD. Fix this by resolving symlinks in the CWD first.
Some compilers (e.g. CHERI LLVM) warn when casting a non-intptr_t integer
type to a pointer. The GSIZE_TO_POINTER() macro thus triggers warnings
which can be silence by casting to guintptr before gpointer.
NB: This macro must not be used to create valid pointers from a integer.
The gutils-user-database.c is broken in two ways and currently doesn't test anything:
* It only overrides getpwuid, where the implementation used getpwnam_r if it exist, which should be every system for at least 20 years.
* It only partly cargo-culted setting the environment for the local and installed tests, but failed to actually set the environment for either.
Before commit 71b7efd08a1feadc8ddca31e164034b1f5a6bd74, `GKeyFile`
incorrectly allowed invalid escape sequences: it would treat the
sequence as a literal, set a `GError`, but not return failure from the
function. So if a caller was explicitly checking for returned `GError`s,
they could detect the invalid escape; but if they were just checking the
function’s return value, they’d miss it.
This is not correct use of `GError`, and the [Desktop Entry
Spec](https://specifications.freedesktop.org/desktop-entry-spec/latest/ar01s04.html)
doesn’t allow for invalid escape sequences to be accepted. So it’s wrong
in both ways.
However, the commit above changed this behaviour without realising it,
quite close to the 2.78 stable release deadline. There are numerous key
files in the wild which use invalid escape sequences, and it’s too late
in the cycle to ‘break’ parsing of all of them.
So, for now, revert to the old behaviour for invalid escape sequences,
and give people another cycle to adapt to the changes. This will likely
mean they end up calling `g_key_file_get_value()` rather than
`g_key_file_get_string()`. See
https://gitlab.gnome.org/GNOME/glib/-/issues/3098 for tracking
re-enabling the error handling for invalid escape sequences.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
Fixes: #3095
See: #3098
pthread_exit() is also marked noreturn, and the function does not in
fact return.
For win32, I can't find a copy of the header file to check if
_endthreadex() is marked with __declspec(noreturn), but its
documentation does say that it never returns.
When parsing a line of "key3=foo\i\" in a keyfile,
g_key_file_parse_value_as_string currently first sets the error to
'contains invalid escape' and later to 'contains escape character at end
of line'.
This leaks the first GError and causes the following warning message:
Error set over the top of a previous GError or uninitialized memory.
This indicates a bug in someone's code. You must ensure an error is
NULL before it's set. The overwriting error message was: Key file
contains escape character at end of line
Fix this by returning when an error is detected. As we may have
collected data in pieces, we instead collect to a tmp_pieces GSList and
free it on error.
On 32 bit systems 'long' value will overflow in 2038 and become negative.
As it is used to index into letters array, and % operation preserves signs,
data corruption will then occur.
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
The point of to be able to call localtime()/localtime_r() from another
place inside glib (without reimplementing the #ifdef).
- also handles failures from localtime_r(). It is documented that it
might fail, so detect the failure.
- in case of failures of localtime(), still initialize the GDate.
Previously, we may error out with a g_critical() assertion before.
However, now that failures from localtime_r() are also caught, I think
we should make an effort to initialize the GDate to something. It
either way it not supposed to happen.
Print the PID, the errno and the pidfd in case of an unexpected failure
in g_child_watch_dispatch().
This is always(?) caused by a bug in the user application. Also hint to
g_child_watch_source_new() documentation for possible causes.
Also use G_PID_FORMAT for printing GPid values.
Prompted by #3071, this clarifies that `g_test_trap_subprocess()` uses
`g_child_watch_source_new()` internally, so it will not work if any of
the preconditions for using that API are not met. In particular, if
`SIGCHLD` is ignored, things will break.
This documentation is not meant to be an API guarantee which constrains
the implementation of `g_test_trap_subprocess()` in future, just a tip
to people currently using the API.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
Helps: #3071
