Fallback code for g_date_time_format_locale() fetches translated
strings (such as day and month names) from .mo catalogues via
gettext. These strings always come in UTF-8 encoding, because
that is the encoding that glib sets when it initializes gettext
for itself.
However, the non-fallback code uses nl_langinfo() and expects
its results to be in locale-dependent encoding.
This mismatch can result in UTF-8 strings being converted to UTF-8,
producing gibberish.
Fix this by converting UTF-8 strings to locale-dependent encoding
before using them. Also fix the code that was already doing the locale->UTF-8
conversion to not convert the strings when they are already UTF-8-encoded.
https://bugzilla.gnome.org/show_bug.cgi?id=766092
There is no need to call g_variant_builder_clear() after the
g_variant_builder_end(). This is mentioned in docs of the former
function, but not in the docs of the latter one. Add them there too.
Later Visual Studio versions does not allow one to define known keywords,
even if they are actually not known to the compiler. Avoid this issue by
checking more conditions before we define inline as __inline:
-We are not building under C++ mode.
-We are on Visual Studio 2013 or earlier.
Where both of these conditions need to hold true.
https://bugzilla.gnome.org/show_bug.cgi?id=765990
Commit 99bdfd1b introduced a direct call to pthreads_setname_np in the
'thread' test case. Because we are directly calling pthreads functions
from this file now, we need to make sure we link it with the system
thread library flags (as we already do for another file).
https://bugzilla.gnome.org/show_bug.cgi?id=765712
The new g_abort() macro just expands to abort() on systems where abort()
behaves in a sane way. On other systems (read: Windows) it does its best
to emulate a sane abort() behaviour.
https://bugzilla.gnome.org/show_bug.cgi?id=665446
This works by using semi-documented[1] exception to tell the debugger
that a thread needs to have its name changed.
If this exception is not caught and handled by something, it will crash
the process, so we need to set up our own handler in case there's no
debugger attached or the debugger can't handle this type of exception.
Since SEH is not supported by gcc on i686 (at the moment), we need to use VEH
instead. For completeness the MSVC-oriented code still uses SEH, although
there is no reason why it shouldn't work with the VEH variant used by MinGW.
VEH handler has to be set up somewhere (g_thread_win32_init () works nicely)
and removed once it's not needed (g_thread_win32_process_detach () is added
expressly for that purpose). Note that g_thread_win32_process_detach() is
only called when glib is unloaded by FreeLibrary(), not when glib-using
process is terminating.
This exception is known to work with WinDbg, and adding support for it into
GDB proved to be feasible (GDB patch will be sent upstream, eventually).
[1] https://msdn.microsoft.com/en-us/library/xcb2z8hs%28v=vs.71%29.aspxhttps://bugzilla.gnome.org/show_bug.cgi?id=747478
We now prefer pthread_setname_np when available, and don't
need the linux specific API anymore. Also change the test
for this functionality to use pthread_getname_np.
Inserts a paragraph in the start of the description
explaining briefly the concept of GVariant as a
variant datatypes using examples and explaining
a few use cases where GVariant can be useful.
https://bugzilla.gnome.org/show_bug.cgi?id=748806
find_file_in_data_dirs() doesn’t actually clear output_path to NULL on
failure, so this prevents a use-after-free on that (fd == -1) error
path.
Spotted by Coverity (CID: #1352981).
Laszlo Ersek said: "The length check is off by one (in the safe direction); it
should be (nchars >= 2). The processing should be active for the wide string
L"\r\n" -- resulting in the empty wide string --, I believe."
Reported-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Marc-André Lureau <marcandre.lureau@gmail.com>
https://bugzilla.gnome.org/show_bug.cgi?id=762202
If the XDG_RUNTIME_DIR environment variable is set, we are being told by
the OS that this directory exists and is appropriately configured
already. In the fallback case of ~/.cache/, however, the directory may
not yet exist.
Rework the logic of this function a little so that we only check for the
environment variable once. If it is not set, we will fall back to the
cache directory, and mkdir() it to make sure that it exists.
Meanwhile, remove a statement from the reference documentation that
promises a warning in this case (which has never been true) and replace
it with a statement that applications can rely on the directory
existing.
This change prevents each user of this API from having to check for the
directory for themselves; an example of that can be seen in bug 763274.
https://bugzilla.gnome.org/show_bug.cgi?id=763344
Previously, calling g_array_remove_range(array, 0, array->len) on an
empty array would result in a precondition failure in
g_array_remove_range(), as the given start index (0), was not strictly
less than the array length (0).
Allow the index to equal the array length, so that zero elements can be
removed from any array. A subsequent check makes sure that the array
length is not overflowed by the index + length.
https://bugzilla.gnome.org/show_bug.cgi?id=763339
Apparently whoever made the last tarball didn't have `--enable-systemtap`.
Disted files shouldn't depend on build flags.
Also, it is cathartic for me to say tarballs are dumb and we should
just be pulling from git which is what's canonically tracking what's
source code and what's not and we don't need to repeat ourself in
`Makefile.am`.
https://bugzilla.gnome.org/show_bug.cgi?id=762637
The scanning to find the end of a positional parameter designator in
GVariant text format (e.g. '%i') is currently broken in case the 'end'
pointer is not specified.
The scan is controlled by a somewhat complicated loop that needs to deal
properly with cases like (123, %(ii)) [where '%(ii)' is to be taken
together, but the final ')' not].
This loop missed the case where a format string passed to
g_variant_new_parsed() ended immediately after such a conversion, with a
nul character. In this case the 'end' pointer is NULL, so the only way
we can find the end is by scanning for nul in the string.
In case of g_variant_new_parsed() [which is what this code was designed
to be used for], the bug is somewhat unlikely in practice: the only way
that a valid text-form GVariant could ever contain a positional
parameter replacement at the end of the string is if this positional
parameter were the only thing being returned. In that case, the user
would likely have opted for a more direct approach.
Unfortunately, this code is also active in the tokenisation phase of
g_variant_parse(), before positional parameters are rejected as invalid
for that case. Anyone who calls this function with a nul-terminated
string (and no end pointer) is vulnerable to a crash from malicious user
input. This can be seen, at the very least with many commandline tools:
$ dconf write /x '%i'
Segmentation fault
We fix this problem by searching for the nul character in this case, in
addition to comparing the end pointer.
This problem is almost certainly limited to being able to cause crashes.
The loop in question only performs reads and, in the security-sensitive
case, the token will be quickly rejected after the loop is finished
(since it starts with '%' and the 'app' pointer is unset). This is
further mitigated by the fact that there are no known cases of GVariant
text format being used as part of a protocol at a privilege barrier.
The start_position arguments are passed to pcre_exec() as the
startoffset, which is in bytes (not characters).
I had recently a doubt about this, so it's better to document it.
https://bugzilla.gnome.org/show_bug.cgi?id=747927
