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>
We presumably want the fallback string used when we cannot determine
the program name to contain balanced angle brackets, as it did before
commit 7098250e.
Fixes: 7098250e "gutils: avoid race setting prgname from g_option_context_parse()/g_application_run()"
Signed-off-by: Simon McVittie <smcv@collabora.com>
This fixes a stack overflow reported by a user who had both the
definition of text/javascript from shared-mime-info 2.3 and the
definition of text/javascript from shared-mime-info 2.4 installed at the
same time. In 2.3, text/javascript is a subtype of
application/ecmascript, but in 2.4 application/ecmascript is a subtype
of text/javascript. Having both at the same time resulted in circular
inheritance.
The new logic keeps a list of all parents that have already been
checked, which is more comprehensive than the old workaround that was
implemented in commit 38869ece2 ("xdgmime: Prevent infinite loops from
badly-formed MIME registrations").
https://bugs.archlinux.org/task/80279
This fixes a load of warnings about ‘multiple comment blocks documenting
<something> identifier’.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3037
Move it to a separate page, since it doesn’t quite make sense to
incorporate into the `GDBusConnection` docs.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3037
Move it to a separate page, as there isn’t a `GIOScheduler` struct.
Ensure that all its functions/methods/types are correctly marked as
deprecated. Fix a few broken links about I/O priority which pointed to
it.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3037
Otherwise the installed one will be used, which will mean that new API
will not be available when linking.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Move it to a separate content page as there is no `GDBusIntrospection`
type to hang the rest of the documentation off.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3037
Adding it all to the docs for the `GDBusError` enum seemed a bit much,
so I moved it to its own content page.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3037
