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
Commit 0817af40e8c74c721c30f6ef482b1f53d12044c7 breaks the build on
older versions of GCC, which don't allow pragma inside functions.
https://bugzilla.gnome.org/761550
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
To update this code you need to fetch the last version of the code
from: https://github.com/win-iconv/win-iconv
Then you need to ensure 3 things:
- the line ends are in unix format
- some of the methods do not expose a const on the prototype
refer to the commit b8c13a01b6bd5601eb3519dd3b20daed4bbc2e72
on how to fix it
- fix one uninitialized variable if not yet fixed upstream
refer to 7e0cb48dee9a8ecd87d403b7941ad3209eee658c
https://bugzilla.gnome.org/show_bug.cgi?id=761126
Rather than calculating it at configure time. This means it can expand
$libdir properly, and use the Make $(realpath) function rather than
invoking the non-portable `readlink -f`.
This fixes problems where `readlink` would be called on an invalid path
(due to a variable not being expanded) and would evaluate to "", which
would then cause things to be installed in the wrong place.
https://bugzilla.gnome.org/show_bug.cgi?id=744772
Commit 855594c changed the expected error for the regex
/(?P<sub>foo)\g<sub/ for PCRE 8.38, but actually PCRE changed the error
raised by this invalid regex in 8.37, so we should check for the new error
from 8.37 and upwards.
Please see comments #21 and #22 of bug 740573 regarding this commit.
To be honest, i don't remember what problems were caused by it returning the
number of bytes it *wanted* to write instead of the number of bytes
it actually wrote. Probably related to the fact that fwrite could
independently fail, and ignoring its return value ignores that error.
https://bugzilla.gnome.org/show_bug.cgi?id=748064
PCRE 8.38 changed the parsing of this invalid regex. It still fails,
but with a different error (since PCRE r1539,
<http://vcs.pcre.org/pcre?view=revision&revision=1539>).
The regex /(?P<sub>foo)\g<sub/ used to raise MISSING_BACK_REFERENCE but
now raises MISSING_SUBPATTERN_NAME_TERMINATOR, so we can still have a
test for the latter.
Signed-off-by: Simon McVittie <smcv@debian.org>
Reviewed-by: Emmanuele Bassi <ebassi@gnome.org>
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=759808
This causes several problems:
- Compilation in FreeBSD with --enable-gtk-doc broke
- Modules that still use the AM_GLIB_GNU_GETTEXT macro
doesnt compile anymore because /usr/share/glib-2.0/gettext
is not filled with the correct files, as this was done in
the glib custom po/Makefile.in.in
See https://bugzilla.gnome.org/show_bug.cgi?id=622991
This reverts commit e5c752371c7fb1343eff27b5f1d0bcbef4e333b9.
Its documentation mentions that it logs a 'critical warning', but since
the macro implementation calls g_warn_message(), it does not log a
critical message, but a regular warning.
Bug 13403 introduced support for the non-POSIX variants of these APIs
found on a system called "DG/UX". Meanwhile, the complicated checks
here are breaking cross-builds on systems that we actually care about.
Remove the complicated checks and replace them with AC_CHECK_FUNCS.
Remove the resulting dead code from a couple of .c files.
https://bugzilla.gnome.org/show_bug.cgi?id=756475
Also get rid of the items regarding G_HAVE_*INLINE as they aren't used
anymore as they are removed from configure.ac.
Thanks to John Emmas and desrt for the earlier patch for getting
rid of the C4005 warnings.
We were trying to squeeze 64-bit test vectors into gsize, which is fine
on 64bit systems but doesn't work very well on 32-bit.
Change that to a guint64.
According to the C spec, any undefined identifier used in a #if
expression is taken to have a numerical value of zero.
Commit db2367e8782d7a39fc3e93d13f6a16f10cad04c2 introduced an #i
statement which depended on this behaviour.
gcc has a -Wundef option which warns about depending on this behaviour,
and unfortunately there are projects that are using -Werror=undef in
builds that include our headers.
Adding a check for defined(__STDC_VERSION__) before using the macro is
enough to silence gcc.
It's been a long time since we've been unconditionally saying "static
inline" in GLib headers without complaints so it's safe to assume that
all compilers that we care about support this.
One thing that is not yet totally supported is the unadorned use of the
word "inline". Depending on the flags (-std=c89, for example), even GCC
will complain about this. Detect missing C99 support and define
"inline" to "__inline" in that case. Some research shows "__inline"
appears to be the most widely-supported keyword here, but we may need to
tweak this if we get some reports of breakage.
Clean up all of the configure checks around this and define G_CAN_INLINE
unconditionally. Unfortunately, we must assume that some people are
still using G_IMPLEMENT_INLINES, we must continue to implement that
(including undefining G_CAN_INLINE and redefining G_INLINE_FUNC) if
requested.
It is not our intent to break existing users of the old-style
G_INLINE_FUNC approach and if that has happened, we may need to make
some further adjustments.
https://bugzilla.gnome.org/show_bug.cgi?id=757374
gutils.h and gutils.c define three utility functions as inlines that are
also exported via the ABI. This is done via complicated G_INLINE_FUNC
and G_IMPLEMENT_INLINES logic.
In order to be able to remove this mess, we create a another convoluted
but slightly cleaner approach: write straight-up inline versions of the
functions named _impl() in the header. Define macros with the "public"
function names that call these inlines. From the .c file, export the
ABI versions of these functions, implemented using the _impl() version.
https://bugzilla.gnome.org/show_bug.cgi?id=757374
Deprecate GTrashStack and remove the inline implementations for the
functions. This will help us clean up the mess that is inline functions
in GLib.
Because of how G_INLINE_FUNC worked, we have these functions on our ABI,
so we must continue to export them as normal functions. We are safe to
remove the inline versions, however, because any existing binaries will
continue to carry them and any new builds will just start using the
non-inline versions.
https://bugzilla.gnome.org/show_bug.cgi?id=757374
Whole program optimization is enabled by default in visual studio
release builds, and this causes constructors (for e.g. resources) to be
optimized away as they are not referenced from elsewhere.
This works around this by some pragma magic.
https://bugzilla.gnome.org/show_bug.cgi?id=752837
Add various (nullable) and (optional) annotations which were missing
from a variety of functions. Also port a couple of existing (allow-none)
annotations in the same files to use (nullable) and (optional) as
appropriate instead.
Secondly, add various (not nullable) annotations as needed by the new
default in gobject-introspection of marking gpointers as (nullable). See
https://bugzilla.gnome.org/show_bug.cgi?id=729660.
This includes adding some stub documentation comments for the
assertion macro error functions, which weren’t previously documented.
The new comments are purely to allow for annotations, and hence are
marked as (skip) to prevent the symbols appearing in the GIR file.
https://bugzilla.gnome.org/show_bug.cgi?id=719966
