On UNIX, we should only ever be looking at TMPDIR.
On Windows, we should only ever look at TEMP.
Also, clean up the documentation to better describe what is actually
happening. The previous docs may have left someone confused about why
this function returns "/var/tmp" on Solaris, even with no TMPDIR set.
https://bugzilla.gnome.org/show_bug.cgi?id=705075
As Visual Studio 2008 and later have support for the __pragma keyword,
where the compiler pragmas can be used in a macro, we can support
G_GNUC_BEGIN_IGNORE_DEPRECATIONS and G_GNUC_END_IGNORE_DEPRECATIONS
for Visual Studio 2008 and later, so many deprecation (C4996) warnings
can be suppressed when using these compilers when we use these macros
in the code.
https://bugzilla.gnome.org/show_bug.cgi?id=704543
This was introduced for Solaris performance theoretically;
we have never been able to use it on Linux/glibc because
the UTF-16 BOM state isn't reset.
We have no data about Solaris performance; were some to
still exist, we could reintroduce the code with an explicit
check for Solaris, not a check for glibc.
https://bugzilla.gnome.org/show_bug.cgi?id=704999
GFileMonitor takes great care to sample the thread-default main context
at the time that it is created in order that events can be dispatched to
the correct thread when they come in.
The inotify GFileMonitor implementation uses a global file descriptor
shared between all watches. It has to poll this file descriptor from
somewhere so it arbitrarily picks the default main context.
The problem with that is that the user might not be running it.
Let's use the GLib worker thread for this instead. It's guaranteed to
be running if you need it, and this is exactly the sort of problem it
was meant to solve.
https://bugzilla.gnome.org/show_bug.cgi?id=704873
We need a TypeName_private_offset variable defined by the macros used to
register dynamic types. We also need to call the adjust_private_offset()
function inside class_init(). G_ADD_PRIVATE_DYNAMIC only sets the size
of the private data structure, and relies on the behaviour of the
g_type_class_adjuset_private_offset() function to register the private
data structure at class init time if passed a value greater than zero.
This allows using G_PRIVATE_OFFSET with dynamic types.
...instead of detecting glibc and using _GNU_SOURCE manually. This
should fix the build when using glibc-emulating libraries; we can
defer portability work to autoconf.
https://bugzilla.gnome.org/show_bug.cgi?id=684123
The timeout-based tests could fail on slow or heavily-loaded machines.
Change them to use a counter-based "timeout" source rather than a
time-based one, so they no longer depend on wall time.
https://bugzilla.gnome.org/show_bug.cgi?id=700460
On a heavily loaded system, it's possible that both our normal
condition *and* the timeout occurred. In that case we can just ignore
the timeout.
While I did add a "sig_timeout" boolean, we don't need to add any
assertions around whether or not it was reached - the assertions
covering the non-timeout case are sufficient. The sig_timeout boolean
is mainly for later debugging.
https://bugzilla.gnome.org/show_bug.cgi?id=700460
If someone creates a unix signal source for e.g. SIGINT, and then
removes it, reset the handler to SIG_DFL.
Not doing this was the source of race conditions in the
glib/tests/unix test, but this will also just make us a "good citizen"
by cleaning up.
For example, if a project temporarily creates a handler for SIGTERM,
and then later removes it, they almost certainly want SIGTERM to
revert to the default of terminating the process, rather than doing
nothing.
https://bugzilla.gnome.org/show_bug.cgi?id=704699
Otherwise in e.g. the gnome-ostree integrationtest system, we
end up sending SIGUSR1 to the *entire session*, which triggers
various badness in untested debugging paths from gnome-session.
This test worked when compiled without optimization, but fails with
-O2. Presumably we just happened to find the GMainLoop off the stack
somewhere.
https://bugzilla.gnome.org/show_bug.cgi?id=704267
GPid is a HANDLE (aka void *) on Windows, not an int, so treat pid
accordingly on Windows, as using pid as a gulong directly would likely be
undesirable on Windows
https://bugzilla.gnome.org/show_bug.cgi?id=704447
The restrictions on partial matching no longer apply with PCRE >= 8.00.
The pcrepartial manpage contains the "FORMERLY RESTRICTED PATTERNS"
section:
"For releases of PCRE prior to 8.00, because of the way certain
internal optimizations were implemented in the pcre_exec() function, the
PCRE_PARTIAL option (predecessor of PCRE_PARTIAL_SOFT) could not be used
with all patterns. From release 8.00 onwards, the restrictions no
longer apply, and partial matching with can be requested for any
pattern."
https://bugzilla.gnome.org/show_bug.cgi?id=704250
- Mention G_SOURCE_CONTINUE and G_SOURCE_REMOVE in the GSourceFunc doc;
- Mention G_PARAM_READWRITE and G_PARAM_STATIC_STRINGS in the
GParamFlags doc;
- Fix "Since:" version for G_DEFINE_ABSTRACT_TYPE_WITH_PRIVATE;
- Fix typo.
https://bugzilla.gnome.org/show_bug.cgi?id=704250
