The code has warned about this since commit 6d9f874330 in 2011.
glibc 2.37 has just started asserting if a `NULL` format is passed to
`sprintf()`, which caused the existing GLib workaround to start
asserting too.
Bite the bullet and upgrade the warning for `format != NULL` to a
critical warning. Projects have had 12 years to fix their code.
The original bug reports
(https://bugzilla.gnome.org/show_bug.cgi?id=660371,
https://bugzilla.gnome.org/show_bug.cgi?id=560482) are actually both
about a domain which is `0`, rather than a format which is `NULL`, which
gives some confidence that this change will actually impact very little
third party code.
Since it doesn’t currently need changing, I have not touched the warning
about `domain != 0`.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2913
On FreeBSD it always crashes due to the platform’s `vasprintf()`
implementation being less forgiving than Linux’s. That’s fine.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This is mostly to cover historic code, but also includes a couple of
additional tests for extended error domains (see #14).
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Some editors automatically remove trailing blank lines, or
automatically add a trailing newline to avoid having a trailing
non-blank line that is not terminated by a newline. To avoid unrelated
whitespace changes when users of such editors contribute to GLib,
let's pre-emptively normalize all files.
Unlike more intrusive whitespace normalization like removing trailing
whitespace from each line, this seems unlikely to cause significant
issues with cherry-picking changes to stable branches.
Implemented by:
find . -name '*.[ch]' -print0 | \
xargs -0 perl -0777 -p -i -e 's/\n+\z//g; s/\z/\n/g'
Signed-off-by: Simon McVittie <smcv@collabora.com>
Even though we can't always make no-leak guarantees when g_warning()
in this case we're testing this behavior in tests, and it would be
good to be able to valgrind this.
https://bugzilla.gnome.org/show_bug.cgi?id=711751
Some of the GLib tests deliberately provoke warnings (or even fatal
errors) in a forked child. Normally, this is fine, but under valgrind
it's somewhat undesirable. We do want to follow fork(), so we can check
for leaks in child processes that exit gracefully; but we don't want to
be told about "leaks" in processes that are crashing, because there'd
be no point in cleaning those up anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=666116
