Put __glib_assert_msg in the dynamic symbol table, but not in any public
headers.
This variable is _not_ part of our API but this way debuggers and
automated crash report utilities will be able to access this variable,
even if debug symbols are not available.
https://bugzilla.gnome.org/show_bug.cgi?id=701800
Fix the warnings when compiling and linking the probes files by
calling dtrace with all the -W flags removed from CFLAGS (since dtrace
generates bad C code), and with CC set to "libtool --mode=compile ..."
(so that it will output a proper .lo file and libtool won't warn when
linking it into the .la).
https://bugzilla.gnome.org/show_bug.cgi?id=693335
test_GDateTime_diff() checks that the span from 2009-01-01 to
2010-01-01 is exactly 365 * G_TIME_SPAN_DAY, but it does this using
local time, and so fails if you are in a timezone that is in the
southern hemisphere which only did DST during one of 2008-2009 and
2009-2010 (in which case the year will end up being one hour too long
or too short).
Switch the diff tests to use UTC time instead; there are plenty of
other local time tests already.
https://bugzilla.gnome.org/show_bug.cgi?id=701529
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
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
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
We can't reset the pending flag for a signal until we've traversed
the whole list, as the documentation clearly says that in case multiple
sources they all get invoked.
This is still racy if you get a signal after checking the flag
but before resetting it, but it was the same before. The correct
fix would be to use sigwait() or signalfd(), but that would mean
blocking all signals in all threads, which is not compatible
with existing applications.
https://bugzilla.gnome.org/show_bug.cgi?id=704322
As the comment says, we may be delayed an arbitrary amount of time on
non-idle systems; update the assertions to reflect this.
This should fix periodic failures in the gnome-ostree continuous
integration system.
https://bugzilla.gnome.org/700460
For some time, the desktop file specification has supported "additional
application actions". This is intended to allow for additional methods
of starting an app, such as a mail client having a "Compose New Message"
action that brings up the compose window instead of the folder list.
This patch adds support for this with a relatively minimal API.
In the case that the application is a GApplication and DBusActivatable,
desktop actions are translated into GActions that have been added to the
application with g_action_map_add_action(). This more or less closes
the loop on being able to activate an application with an action
invocation (instead of 'activate').
https://bugzilla.gnome.org/show_bug.cgi?id=664444
Fix some leaks that turned up while valgrinding the GVariant testcase.
These leaks are small and only occur when there is already an error in
the program: they are leaks of temp strings used when formatting a
critical message.
These show up as leaks again the testcase under the new "expect
messages" approach. Previously, we fork()ed and these caused the
subprocess to abort, which is why this was not noticed before.
Otherwise we have to rely on pthread_cond_timedwait() actually using
the monotonic clock, which might be true or not. On Android at least
it is using the realtime clock, no pthread_condattr_setclock() is available
but instead pthread_cond_timedwait_monotonic() can be used.
This reverts commits dfbac178bd and
56348210f3.
These two commits introduce undesirable behaviour and were made with no
apparent approval from anybody at all, and without reference to a bug or
mailing list discussion.
Even when the app author specifies G_SPAWN_LEAVE_DESCRIPTORS_OPEN,
we should avoid leaking our internal pipe machinery into the
child.
Commit message written by: Colin Walters <walters@verbum.org>
https://bugzilla.gnome.org/show_bug.cgi?id=703407
In order to fully undo the effects of g_mutex_init(),
it is necessary to reset the internal mutex pointer
back to NULL so that a later call to g_mutex_init()
actually works as expected.
Recent versions of clang have changed __PRETTY_FUNCTION__ to always
include the function signature (rather than including the function
signature in C++ but not in C like gcc does). This causes G_STRFUNC to
give different results under clang and gcc, causing some tests with
g_test_expect_messages() to fail.
Fix this by only using __PRETTY_FUNCTION__ in C++, and using
__FUNCTION__ in C. (Under gcc this change has no effect.)
https://bugzilla.gnome.org/show_bug.cgi?id=702147
When a child_source is added to a blocked source it has no context, yet we
call block_source on it that segfaults when it dereferences the NULL context
when it attempts to remove the file descriptors. To fix this we:
- Ensure that when we block a source, we don't attempt to remove its file
descriptors from a NULL context.
- Also ensure that when we attach a blocked source to a context, we don't add the
file descriptors to the context.
https://bugzilla.gnome.org/show_bug.cgi?id=701283
We didn't actually do any real-world testing of this, and
unsurprisingly it turns out to break in at least one widely-used
configuration (Fedora 19 x86_64, ext4 on LVM).
This reverts commit 9d0c17b501.
https://bugzilla.gnome.org/show_bug.cgi?id=701560
ext3 and ext4 (for quite some time) with default mount options don't
need fsync() to ensure safety of replace-by-rename. Stop doing that for
these filesystems.
Note: this patch also impacts ext2, which is probably not safe, but I
don't know of any way to check ext2. vs the others because they all have
the same magic numbers (short of opening /proc/mount).
This patch assumes that if BTRFS_SUPER_MAGIC is defined then so will be
EXT3_SUPER_MAGIC.
https://bugzilla.gnome.org/show_bug.cgi?id=701560
Use a normal write() system call instead of fdopen() and fwrite().
This will definitely work on UNIX system and should work on Windows as
well...
As an added bonus, we can use g_close() now as well.
https://bugzilla.gnome.org/show_bug.cgi?id=701560
g_file_set_contents() sets a GError in the event of various failures
that count occur. It uses g_filename_display_name() in order to get the
filename to include in the messages.
Factor out the error handling to make it easier to allocate the display
name only when we need it (instead of allocating it every time).
https://bugzilla.gnome.org/show_bug.cgi?id=701560
Extents-based filesystems like knowing in advance how much data will be
written to a file in order to prevent fragmentation. If we have it, use
posix_fallocate() before writing data in g_file_set_contents().
https://bugzilla.gnome.org/show_bug.cgi?id=701560
Perform a substantial cleanup of the build system with respect to
building and installing testcases.
First, Makefile.decl has been renamed glib.mk and substantially
expanded. We intend to add more stuff here in the future, like canned
rules for mkenums, marshallers, resources, etc.
By default, tests are no longer compiled as part of 'make'. They will
be built when 'make check' is run. The old behaviour can be obtained
with --enable-always-build-tests.
--disable-modular-tests is gone (because tests are no longer built by
default). There is no longer any way to cause 'make check' to be a
no-op, but that's not very useful anyway.
A new glibtests.m4 file is introduced. Along with glib.mk, this
provides for consistent handling of --enable-installed-tests and
--enable-always-build-tests (mentioned above).
Port our various test-installing Makefiles to the new framework.
This patch substantially improves the situation in the toplevel tests/
directory. Things are now somewhat under control there. There were
some tests being built that weren't even being run and we run those now.
The long-running GObject performance tests in this directory have been
removed from 'make check' because they take too long.
As an experiment, 'make check' now runs the testcases on win32 builds,
by default. We can't run them under gtester (since it uses a pipe to
communicate with the subprocess) so just toss them in TESTS. Most of
them are passing on win32.
Things are not quite done here, but this patch is already a substantial
improvement. More to come.
This should be the last users that need to be ported.
For some of the oldschool non-gtester-ified tests, we call g_test_init()
from main() because it is necessary in order to use
g_test_build_filename().
Since this feature is so utterly automake-centric, we may as well be
using the same terminology as automake itself (ie: although it's
BUILT_SOURCES, it's DIST_EXTRA, not DISTED).
Also add some comments to the enum explaining that these terms are
really corresponding directly to the automake terms.
https://bugzilla.gnome.org/show_bug.cgi?id=549783
Add a pair of functions for returning strings that don't need to be
freed. This is a bit of a hack but it will turn the 99% case of using
these functions from:
gchar *tmp;
tmp = g_test_build_filename (...);
fd = open (tmp, ...);
g_free (tmp);
to:
fd = open (g_test_get_filename (...), ...);
which is a pretty substantial win.
https://bugzilla.gnome.org/show_bug.cgi?id=549783
Windows doesn't define STDOUT_FILENO and STDERR_FILENO, and they're
not even guaranteed to be 1 and 2. So just use stdio instead. Also fix
a counting error. Pointed out on gtk-devel-list.
Back in the far-off twentieth century, it was normal on unix
workstations for U+0060 GRAVE ACCENT to be drawn as "‛" and for U+0027
APOSTROPHE to be drawn as "’". This led to the convention of using
them as poor-man's ‛smart quotes’ in ASCII-only text.
However, "'" is now universally drawn as a vertical line, and "`" at a
45-degree angle, making them an `odd couple' when used together.
Unfortunately, there are lots of very old strings in glib, and also
lots of new strings in which people have kept up the old tradition,
perhaps entirely unaware that it used to not look stupid.
Fix this by just using 'dumb quotes' everywhere.
https://bugzilla.gnome.org/show_bug.cgi?id=700746
Since we expect them to crash, let's not spam the system
core dump collection (systemd, abrt). At the moment
systemd is not very robust against programs crashing
in loops.
Instead of aborting, we exit(1).
https://bugzilla.gnome.org/show_bug.cgi?id=700714
See https://live.gnome.org/GnomeGoals/InstalledTests for more
information.
The tests now support being run both uninstalled and installed, so
'make check' works for those who want it. For tests which need data
files, the way this works is they look in the compiled in value of
SRCDIR by default, and the generated tests use "env G_TEST_DATA=" to
override that.
This patch only converts glib/tests for now; if this patch looks good,
I'll do the rest of the tests.
https://bugzilla.gnome.org/show_bug.cgi?id=699079
Rather than overloading --verbose, just skip the tests that aren't
supposed to be run in the parent process (so that if you do run the
toplevel test with --verbose, it doesn't immediately error out).
https://bugzilla.gnome.org/show_bug.cgi?id=679683
g_test_trap_fork() doesn't work on Windows and is potentially flaky on
unix anyway given the fork-but-don't-exec. Replace it with
g_test_trap_subprocess(), which re-spawns the same program with
arguments telling it to run a specific (otherwise-ignored) test case.
Make the existing g_test_trap_fork() unit tests be unix-only (they
never passed on Windows anyway), and add a parallel set of
g_test_trap_subprocess() tests.
Also fix the logic of gtestutils's "-p" argument (which is used by the
subprocess tests); previously if you had tests "/foo/bar" and
"/foo/bar/baz", and ran the test program with "-p /foo/bar/baz", it
would run "/foo/bar" too. Fix that and add tests.
https://bugzilla.gnome.org/show_bug.cgi?id=679683
Not sure why it was doing this, but it's not necessary (all of glib's
tests pass fine without it), and it breaks tests that try to use
g_spawn_sync() or GChildWatchSource after doing a g_test_trap_fork().
https://bugzilla.gnome.org/show_bug.cgi?id=679683
Ryan accidentally committed some debugging code a long time ago,
causing this file to always use futex emulation even when real futex
support was available. I noticed this a while later and pointed it out
to him, and assumed he was going to fix it, but I guess he assumed I
was going to fix it, and then neither of us did...
https://bugzilla.gnome.org/show_bug.cgi?id=699500
This ancient code was attempting to cope with (unknown) systems whose
malloc() prototype was incompatible with the standard. This test was
fragile; it would break if the build environment provided -Wall in
CFLAGS.
Now that it's 2013, let's assume that target systems have a sane
malloc(). If someone complains, we can revisit this.
https://bugzilla.gnome.org/698716
This partially reverts commit ce0022933c.
It used to be safe to use g_spawn_sync() from processes that had their
own SIGCHLD handler because it simply called wait(). When it was
changed to depend on the GLib child watching infrastructure this meant
that GLib had to own the SIGCHLD handler.
This caused hangs in at least Pidgin.
The patch contained two other improvements to the child watch code which
we want to keep, so only revert the changes to gspawn itself.
https://bugzilla.gnome.org/show_bug.cgi?id=698081
All experienced GLib hackers know that G_SLICE=always-malloc is
absolutely essential when valgrinding but many users of GLib don't know
about this and get hit pretty hard when valgrinding their programs.
When initialising gslice, add a check to see if we are running under
valgrind and disable ourselves if we are.
We only do the check in the case that G_SLICE= was not specified in the
environment, so setting it to an empty string will prevent this default
behaviour.
I considered modifying gslice to use the VALGRIND_MALLOCLIKE_BLOCK
client request in all cases in order to just mark the blocks properly
but these calls are not free and gslice is pretty hyper-optimised. It's
easier to just disable gslice completely and this way we only have to do
one check during startup. It's also theoretically possible that someone
might want to use valgrind to debug gslice, in which case the extra
annotations would probably cause quite a lot of difficulty.
https://bugzilla.gnome.org/show_bug.cgi?id=698595
This is a BSD-licenced header file that is designed to be copy-pasted
into programs. It will allow us to detect if we are running under
Valgrind and send "client requests" to it.
We will use this for a couple of reasons in upcoming patches.
https://bugzilla.gnome.org/show_bug.cgi?id=698595
Lots of people have variously asked for APIs like
g_variant_new_string_printf() in order to avoid having to use
g_strdup_printf(), create a GVariant using g_variant_new_string(), then
free the temporary string.
Instead of supporting that, plus a million other potential cases,
introduce g_variant_new_take_string() as a compromise.
It's not possible to write:
v = g_variant_new_take_string (g_strdup_printf (....));
to get the desired result and avoid the extra copies. In addition, it
works with many other functions.
https://bugzilla.gnome.org/show_bug.cgi?id=698455
Parsing wrongly-typed GVariant text format data is a well-defined
operation and it ought to result in a GError. We do that for most
cases, but 'v' and 'ay' were being treated differently. Fix those as
well.
set/endpwent are only required for iterating through passwd entries
using getpwent(). Since we are explicitly requesting a passwd entry
for a uid then the set/endpwent calls are redundant.
Removing these redundant calls is required for building on Android
since their C library doesn't implement these.
https://bugzilla.gnome.org/show_bug.cgi?id=645881
When unreffing a context with sources still attached, it would end up
unlocking an already-unlocked context, causing crashes on platforms
that (unlike Linux) actually check for that.
https://bugzilla.gnome.org/show_bug.cgi?id=697595
RHEL6 ships with GCC 4.4 by default, which doesn't understand the
nicer deprecated attribute that takes a message. However, we can at
least fall back to the old G_DEPRECATED, rather than silently doing
nothing.
This gives me warning messages when building OSTree on RHEL6 when I
accidentally added a usage of g_unix_fd_source_new().
https://bugzilla.gnome.org/show_bug.cgi?id=697160
Like all macros, we need to parenthesize arguments to ensure the order
of operations is correct.
See the mail thread starting at
<http://lists.fedoraproject.org/pipermail/devel/2013-March/180302.html>
"GCC produced wrong code in gvfs-1.14.2-3.fc18.x86_64" for how this
caused trouble with GVFS (which in turn caused trouble with
LibreOffice, where running "soffice sftp://.../.../test.odt" to access
an .odt file via GVFS failed to properly type-detect that file as a
Writer document and produced bogus error messages about the file being
broken).
https://bugzilla.gnome.org/show_bug.cgi?id=695925
Unicode corrigendum #9 spells out in no uncertain terms that on
conversion interfaces we should not reject characters like U+FFFE and
U+FFFF which we were doing before.
Commit f91ef4ef15 started accepting these
characters, but we had some testcases that were checking that strings
containing these characters should be rejected.
Update the tests.
https://bugzilla.gnome.org/show_bug.cgi?id=694669
I added these because the older mingw32 toolchain didn't have
MemoryBarrier(). The newer mingw-w64 toolchain however has.
As reported by John Emmas this was causing build failure with
MSVC because of inline issues. But that reminded me that we
may be taking this path even if the system implements
MemoryBarrier as a function, which is a waste. So, just remove
it.
The newer Microsoft CRTs (8.0/2005 and later) impose much stricter
(paranoid) checks on close() being doubly called and the use of
invalid file descriptors. This makes the calls on the file descriptors
use more caution when using them and only call close() when necessary.
This also adds an (empty) invalid parameter handler* as required by the
newer Microsoft CRTs to prevent the system from aborting the process
when we are checking whether a file descriptor is valid.
[*]: http://msdn.microsoft.com/en-us/library/a9yf33zb.aspxhttps://bugzilla.gnome.org/show_bug.cgi?id=693646
Some (broken) toolchains for example trip up
-Werror=missing-prototypes in system headers. This patch allows
people to skip the formerly hardcoded "baseline" warnings.
https://bugzilla.gnome.org/show_bug.cgi?id=694757
We can detect list corruption in some cases. The new test case
demonstrates a case where we can warn instead of silently corrupt
the list. This was pointed out by Steve Grubb.
Also, use the same auxiliary routine in all places where we unlink
a list element.
In the case that the "HOME" environment variable is set (as it is under
normal circumstances), we don't really need to be opening /etc/passwd.
For historical reasons (ie: how we used to ignore $HOME) and due to the
grouping of many unrelated things together (reading username, hostname,
home directory, tmpdir, etc.) into one function we were still opening
/etc/passwd in g_get_home_dir(), even if $HOME was set.
Since earlier commits removed code from it, all that remains in
g_get_any_init_do() is the logic for dealing with $HOME and reading the
password database.
We now split the logic to deal with $HOME into g_get_home_dir(). With
only the password database functionality remaining, g_get_any_init_do()
is renamed to g_get_user_database_entry() and modified not to set global
variables but rather return a struct. If g_get_home_dir() cannot find
$HOME, it falls back to calling g_get_user_database_entry() and using
the home directory from there.
Use of the 'g_utils_global' lock is further reduced by using
g_once_init_enter() to protect the critical sections in each of
g_get_user_database_entry() and g_get_home_dir().
Finally, the g_get_user_name() and g_get_real_name() functions are
modified to use the new regime.
https://bugzilla.gnome.org/show_bug.cgi?id=693204
Some code was directly calling g_get_any_init() and then expecting to be
able to use the static 'g_home_dir' variable directly. Change these
over to g_get_home_dir() instead.
https://bugzilla.gnome.org/show_bug.cgi?id=693204
This is a source-compatible change and only breaks ABI with respect to
truly ancient binaries (and those binaries are already broken for other
reasons).
Back in the day, functions like g_get_user_name() used to return strings
in the system codepage instead of utf8 (as they do today).
It was decided at some point to change these functions to return utf8,
breaking source compatibility but keeping ABI compatibility. This was
done by exporting new symbols with names like g_get_user_name_utf8() and
using a #define of the old name over to the new name (so that newly
compiled code would link against the _utf8 version, but old binaries
would continue to use the non-utf8 variant).
Meanwhile, glib has undergone several ABI breaks on Windows since, so
those old binaries don't work anymore.
Start to clean up this mess by removing the #define renaming. New
binaries calling g_get_user_name() will now link against
g_get_user_name() and it will return utf8.
We must keep the functions like g_get_user_name_utf8() for binary
compatibility with recently built programs (ie: ones built with the
renaming). Nobody should have ever been calling these directly and of
course they can return utf8, so just add them as internal wrappers in the
.c file and declare them _GLIB_EXTERN there.
One day, if we feel like breaking Windows ABI again, we can finish the
cleanup by dropping the wrappers. There is some talk of introducing
something like 'ABI compatible for two years' and this change would be
compatible with such a regime.
https://bugzilla.gnome.org/show_bug.cgi?id=693204
If there are options that need their names to be aliased, keep track
of that internally rather than modifying the passed-in GOptionGroup
(and leaking strings in the process).
https://bugzilla.gnome.org/show_bug.cgi?id=682560
The default handler test was not unsetting the log handler that
gets installed by GTest, which causes the log messages to be duplicated
on stdout if --verbose or --tap are passed. This in turn can make some
of the non-match checks fail. Since we are already using g_test_trap_fork,
we can just unset the handler in the child.
GHashTable remains a set for as long as all of the keys are exactly
equal (in pointer value) to all of the values. We check this by
comparing keys to values when we do inserts.
Unfortunately, when doing g_hash_table_insert() when a key is already in
the table, the old key pointer value is kept, but the new value pointer
is used. Now we have a situation where a key pointer is unequal to a
value pointer, but we were not treating this case properly.
Fix that.
https://bugzilla.gnome.org/show_bug.cgi?id=692815
Since this is a new API this cycle it's a good time to add a doc comment
explicitly declaring that a confusing issue that could be resolved
either way has no specific defined behaviour.
This may allow us some additional freedom in future GMainContext work or
we may decide that one behaviour is more desirable than the other.
There are two benefits to this:
1) We can centralize any operating system specific knowledge of
close-vs-EINTR handling. For example, while on Linux we should never
retry, if someone cared enough later about HP-UX, they could come by
and change this one spot.
2) For places that do care about the return value and want to provide
the caller with a GError, this function makes it convenient to do so.
Note that gspawn.c had an incorrect EINTR loop-retry around close().
https://bugzilla.gnome.org/show_bug.cgi?id=682819
GVariant has the concept of fixed-sized types (ie: types for which all
values of the type will have the same size). Examples are booleans,
integers, doubles, etc. Tuples containing only these types are also
fixed size.
When GVariant is trying to deal with a fixed-sized value for which it
doesn't have a sufficient backing store (eg: the case where a
fixed-sized value was created with g_variant_new_data() with an
incorrect number of bytes) it denotes this by setting the size of the
value to the correct fixed size but using a NULL data pointer.
This is well-documented in several code comments and also in the public
API documentation for g_variant_get_data() which describes the situation
number which NULL could be returned.
The decision to deal with this case in this way was changed at the last
minute around the time that GVariant was merged -- originally we had an
elaborate setup involving allocating an internal buffer of sufficient
size to be shared between all invalid values.
Unfortunately, when making this change a small detail was missed.
gvs_tuple_get_child() (the function responsible for deserialising
tuples) was updated to properly check for this case (and it contains a
comment about why it must). gvs_tuple_is_normal() (the function
responsible for verifying if a tuple is in normal form) was not.
We add the check now.
Note that this problem does not exist with any other container type
because tuples are the only container capable of being fixed-sized. All
other container types (arrays, maybes, variants) can contain a variable
number of items or items of variable types (note: we consider dictionary
entries to be two-tuples). The code for validating non-container values
also contains a check for the case of NULL data.
The problem also does not occur in the only other function dealing with
serialised tuples: gvs_tuple_n_children(). Whereas other container
types would have to inspect the serialised data to determine the number
of children, for tuples it can be determined directly from the type.
We have various sub directories in glib/ and gio/ (eg: inotify, gnulib,
pcre, xdgmime, etc.) that build convenience libraries that are then
included into libglib and libgio. The files in these directories need
to be built with the same visibility policy as the files in the first
level directories, so add CFLAGS for them all.
This wasn't a problem when the visibility flags were set directly in
CFLAGS but then we had to deal with some modules that we built that we
explicitly wanted to export symbols from.
For now, we can keep things the way they are because it's less hacky and
although it's a theoretical hazard to forget these CFLAGS, we rarely add
new subdirectories to the build.
Before this commit, the only difference between the expected and actual
ABI were the addition of _init and _fini symbols in each module (now
that regexp-based export control is not catching those).
Adding file descriptors to a GSource provides similar functionality to
the old g_source_add_poll() API with two main differences.
First: the list of handles is managed internally and therefore users are
prevented from randomly modifying the ->events field. This prepares us
for an epoll future where changing the event mask is a syscall.
Second: keeping the list internally allows us to check the ->revents for
events for ourselves, allowing the source to skip implementing
check/prepare. This also prepares us for the future by allowing an
implementation that doesn't need to iterate over all of the sources
every time.
https://bugzilla.gnome.org/show_bug.cgi?id=686853
Allow for NULL GSourceFuncs.check() and .prepare().
For prepare() the source will be taken not to be ready and having an
infinite timeout. For check() the source will be taken not to be ready.
https://bugzilla.gnome.org/show_bug.cgi?id=686853
This is the vtable pointer for the source which is usually held in
static storage. For our internal sources it points at a vtable which
the user should really never be modifying.
Mark it const.
https://bugzilla.gnome.org/show_bug.cgi?id=686853
We only want to control the default visibility for our five main
installable libraries: libglib, libgthread, libgmodule, libgobject,
libgio. We should therefore only set -fvisibility=hidden when building
those.
Use a separate substitution variable for this purpose.
Using CFLAGS directly leads to some modules built in testcases not
exporting their symbols (and then the tests fail). It also affects the
fam file monitoring module.
Colin had originally done it this way in his visibility patch series but
I failed to understand why so I didn't copy it. Now I do.
Also: revert changes made to two testcases in an attempt to work around
this issue.
https://bugzilla.gnome.org/show_bug.cgi?id=691756
With visibility now under the control of __declspec(dllexport) we no
longer need to build .def files or use them for building our various
.dll files.
.def files used to be installed (even though it is only really useful
when creating the .dll or .lib file). Don't do that anymore either.
The Makefiles still contain rules to create a .lib file for use with
Visual Studio and these rules require .def files. There are special
requirements to using these rules (like having installed and setup
Microsoft tools for use during the build) and therefore the problem of
creating a .def file for use with them is left open to anyone willing to
make the effort. Many options are available depending on which
toolchain is in use (dlltool, pexport, gendef, dumpbin.exe, just to name
a few).
If we can find a free tool for creating .lib files in the future, we
should probably revisit this issue and add proper support back to our
build system.
We have a public symbol 'glib_on_error_halt' that is exported from
gbacktrace.c without appearing in a header, presumably with the
intention that people will be able to hit it from their debugger.
Mark it as GLIB_AVAILABLE_IN_ALL from inside the .c file...
https://bugzilla.gnome.org/show_bug.cgi?id=688681
This macro simply evaluates the "extern" unless it has been explicitly
defined to something else.
All of the version macros (including the unversioned deprecation markers
and GLIB_AVAILABLE_IN_ALL) now include _GLIB_EXTERN as part of their
definition.
G_INLINE has also been modified to use _GLIB_EXTERN where appropriate.
This macro should never be used outside of the gmacros.h/gversonmacros.h
headers.
The effect of this patch is that "extern" has now been added to all
functions declared in installed headers. Strictly speaking, this is
something we should have had all along...
GLIB_VAR and GOBJECT_VAR have also been modified to use _GLIB_EXTERN on
non-Windows, instead of "extern" which they were using before. The
eventual goal is to use the normal version/deprecation macros on
exported variables and drop GLIB_VAR but we need to see how this will
work on Windows before we go ahead with that.
https://bugzilla.gnome.org/show_bug.cgi?id=688681
Add the GLIB_AVAILABLE_IN_ALL annotation to all old functions (that
haven't already been annotated with the GLIB_AVAILABLE_IN_* macros or a
deprecation macro).
If we discover in the future that we cannot use only one macro on
Windows, it will be an easy sed patch to fix that.
https://bugzilla.gnome.org/show_bug.cgi?id=688681
Add a macro to declare that a particular symbol is available in all
versions of GLib.
All newly-added symbols should have proper version macros (like
GLIB_AVAILABLE_IN_2_36) and this macro is less likely to get used 'by
accident' for those than one with a name like GLIB_EXTERN or
GLIB_PUBLIC.
https://bugzilla.gnome.org/show_bug.cgi?id=688681
This allows compilation with clang without errors, even when
-Wformat-nonliteral is active (as long as there are no real cases of
non literal formatting).
https://bugzilla.gnome.org/show_bug.cgi?id=691608
Rather than overloading --verbose, just skip the tests that aren't
supposed to be run in the parent process (so that if you do run the
toplevel test with --verbose, it doesn't immediately error out).
https://bugzilla.gnome.org/show_bug.cgi?id=679683
If you had two tests "/foo/bar" and "/foo/bar/baz", and ran the test
program with "-p /foo/bar/baz", it would run "/foo/bar" too. Fix that.
And add a test to tests/testing for it.
https://bugzilla.gnome.org/show_bug.cgi?id=679683
g_test_trap_fork() doesn't work on Windows and is potentially flaky on
unix anyway given the fork-but-don't-exec. Replace it with
g_test_trap_subprocess(), which re-spawns the same program with
arguments telling it to run a specific (otherwise-ignored) test case.
Make the existing g_test_trap_fork() unit tests be unix-only (they
never passed on Windows anyway), and add a parallel set of
g_test_trap_subprocess() tests.
https://bugzilla.gnome.org/show_bug.cgi?id=679683
Some compilers assume a literal value is a certain byte-length without
checking the type to which it is being assigned, giving a compile-time
warning: a default of 'long' is a mismatch when assigning to a guint64
when the latter is a 'long long'. Use one of glib's standard macros to
specify the type of the constant to match the variable type.
https://bugzilla.gnome.org/show_bug.cgi?id=688829
The approach of sucking a zoneinfo file into a GBytes and working with
pointers into it might be fast, but it's obtuse and not compatible with
Microsoft Windows.
In 2.34, g_compute_checksum_for_bytes() was added, but this patch
allows binding users to use the incremental update API; this is
significantly more efficient than reading entire files into memory.
https://bugzilla.gnome.org/show_bug.cgi?id=689982
If the $HOME environment variable is set, prefer that to the entry in
/etc/passwd.
This brings us in line with almost every other utility and library on
UNIX-like systems while avoiding some of the more complicated
possibilities that have been suggested.
This incompatible change has been petitioned for quite some time by
many, and in particular from the Debian world, which carries a patch
that adds a new G_HOME environment variable with the same meaning as
this patch now assigns to HOME.
The primary motivation for the change was to increase the testability of
GLib-based programs from 'make check' types of frameworks: it is now
possible to set HOME to a temp directory to avoid the testsuite
modifying the user's real home directory.
The change also brings us increased compliance with the XDG Base
Directory Specification. The specification specifically states that the
default values should be computed based on the HOME environment
variable, whereas we were basing them on the value from /etc/passwd.
The change was agreed to by all in attendence at the November 29 Gtk+
developer meeting.
https://bugzilla.gnome.org/show_bug.cgi?id=142568
When running a test program (ie, if g_test_init() has been called),
don't pop up a dialog box when a fatal error occurs. Just print the
message to stderr and exit.
https://bugzilla.gnome.org/show_bug.cgi?id=679683
Just like g_timeout_add() and friends, we want to hide the unintrospectable
g_unix_signal_add() from GI bindings and present g_unix_signal_add_full() as
GLib.unix_signal_add() to them.
Add aliases for codesets supported by iconv and included in locales.
Ifdef-out tests in glib/tests/gdatetime.c which fail because on OSX only
ASCII numbers or symbols are returned for the format.
Even though nl_langinfo does weird things on Darwin in some cases, it
still acts correctly when LANG/LC_ALL is set to a supported
locale.codeset.
Apply slightly modified patch from Camillo Lugaresi which fixes
gunicollate for OSX >= 10.6. It was totally hilariously broken
for anyone on 10.6 and later, I dont know if it's now broken
on 10.5, but better fix it for the vast majority of users.
The previous fix didn't work, because every place within glib that
used any of the functions also needed to be including win32compat.h.
So, move the prototypes back to their original headers (but at least
all in one place at the bottom).
https://bugzilla.gnome.org/show_bug.cgi?id=688109
A few gtestutils function use long double as a type that can (in
theory) hold any int or any double. But win32 doesn't support long
doubles in printf, so convert them to ints or doubles first before
trying to print them.
https://bugzilla.gnome.org/show_bug.cgi?id=688109
glib/tests/test-printf tests some non-standard printf formats on
Windows, which gcc doesn't recognize, and so complains about. Disable
those warnings for that test.
https://bugzilla.gnome.org/show_bug.cgi?id=688109
gvariant-internal.h was defining GLIB_COMPILATION so that it could
include individual headers, but this broke tests/gvariant on windows
because setting GLIB_COMPILATION changes the definition of GLIB_VAR,
causing external variables to not be found. Fix this by having it
define __GLIB_H_INSIDE__ instead.
https://bugzilla.gnome.org/show_bug.cgi?id=688109
Rather than using "extern" declarations of these win32 functions
everywhere they're needed, just prototype them in glib-private.h.
(Which also fixes the fact that they weren't prototyped in the files
where they're defined.)
https://bugzilla.gnome.org/show_bug.cgi?id=688109
To avoid -Wmissing-prototype warnings, we need to prototype both the
original and the _utf8 versions of all of the functions that have had
_utf8-renaming on Windows. But duplicating all the prototypes is ugly,
so rather than doing them "in-place", move them all to a new header
file just for that.
https://bugzilla.gnome.org/show_bug.cgi?id=688109
This avoids collecting the zombie child, which means that the PID
can't be reused. This prevents possible race conditions that might
occur were one to send e.g. SIGTERM to a child.
This race condition has always existed due to the way we called
waitpid() for the app, but the window was widened when we moved the
waitpid() calls into a separate thread.
If waitid() isn't available, we return NULL, and consumers of this
private API (namely, GSubprocess) will need to handle that.
https://bugzilla.gnome.org/show_bug.cgi?id=672102
Commit 138f4c1 broke the relevant part of 'make check' by changing the
error messages away from the ones we previously expected. This commit
updates the expected output to catch up.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=688255
Reviewed-by: Matthias Clasen <mclasen@redhat.com>
0 is not a valid source id, but for long-lived programs that rapidly
create/destroy sources, it's possible for the source id to overflow.
We should handle this, because the documentation implies we will.
https://bugzilla.gnome.org/show_bug.cgi?id=687098
Make g_byte_array_new() and g_byte_array_new_take() introspectable by adding
missing transfer annotations to return value.
Covered by tests in PyGObject.
Annotate g_bytes_new*()'s data argument to be a guint8 array, as
introspection clients cannot deal with raw gconstpointers. This makes
GBytes' behaviour similar to GByteArray whose API already uses guint8.
Add missing transfer annotation to g_bytes_get_data() to make it
introspectable.
This is covered by test cases in PyGObject.
See https://bugzilla.gnome.org/show_bug.cgi?id=686185
This skips the test on those systems, like Darwin, which provide the
ja_JP.eucjp locale but which glib doesn't know how to transcode and
aliases JIS to UTF-8.
open() is probably defined varargs. Casting a varargs function to an
equivalent non-varargs type and then calling it is undefined, but
gfileutils.c was doing exactly that.
Add some non-varargs wrappers to avoid the problem.
Problem reported by John Spencer.
https://bugzilla.gnome.org/show_bug.cgi?id=687600
The GLib units policy used to be that 'KB' means 1024 bytes, 'MB' means
1024 KB, 'GB' means 1024 MB, etc.
Those days are over, but we have a deprecated function that still works
that way. It contains the string "KB", marked for translation, which
has been a source of confusion for translators on multiple occasions.
https://bugzilla.gnome.org/show_bug.cgi?id=687516
bytes_read and bytes_written are (out) arguments, and the return value must be
a byte array instead of utf8, as otherwise the function would only support
UTF-8 locales/file names.
This is preparatory work for a future commit which will add a
"catchall" waitpid API. If we don't synchronize here with the worker
thread, race conditions are possible.
This also ensures we have an error message if someone adds a child
watch for a nonexistent pid, etc. Previously, we'd simply keep
calling waitpid() getting ECHILD, and ignoring it until the source was
removed. Now, we g_warning() and fire the source.
Thirdly, this ensures that the waitpid() call in gmain handles EINTR,
like the g_spawn_sync() one did.
https://bugzilla.gnome.org/show_bug.cgi?id=687061
Sadly, g_slice_debug_tree_statistics is conditionally part of the
public ABI. We might as well make it conditionally part of the API as
well, even though this will require people actually using it to
https://bugzilla.gnome.org/show_bug.cgi?id=687385
On platforms where dependent loads can be reordered (alpha) and we have
exotic implementation of pthread_mutex_lock() it could be possible that
our implementation of g_mutex_lock() is unsafe.
Always use atomic operations to avoid this possibility.
https://bugzilla.gnome.org/show_bug.cgi?id=686191
Applications that use glib should not invoke waitpid with a first
argument that is nonpositive, because when such a waitpid is run in
one thread and glib waits for a subprocess in another, there is a race
condition, and the former waitpid can reap a process that was intended
for the latter. Mention this in the documentation for
g_child_watch_source_new, and in the diagnostic generated by
g_spawn_sync when its waitpid fails with errno equal to ECHILD.
Signed-off-by: Colin Walters <walters@verbum.org>
http://bugzilla.gnome.org/show_bug.cgi?id=687075
The various read and write methods have several out arguments which were not
previously marked as such. Also, as GIOChannel supports binary data with a NULL
encoding, the buffers need to be uint8 arrays instead of utf8 strings.
... and don't spam stderr with exceptions if someone renames things
again.
Last but not least, keep the old names as a fallback, so that LD_PRELOAD
with an older libglib still works.
-Make config.h.win32(.in) have entries that more resembles the generated
config.h.in
-Move the ALIGNOF_* #define's from glibconfig.h.win32(.in) to
config.h.win32(.in), where they were supposed to be.
Some programs attempt to use libglib (or even libgio) when setuid.
For a long time, GTK+ simply aborted if launched in this
configuration, but we never had a real policy for GLib.
I'm not sure whether we should advertise such support. However, given
that there are real-world programs that do this currently, we can make
them safer with not too much effort.
Better to fix a problem caused by an interaction between two
components in *both* places if possible.
This patch adds a private function g_check_setuid() which is used to
first ensure we don't run an external dbus-launch binary if
DBUS_SESSION_BUS_ADDRESS isn't set.
Second, we also ensure the local VFS is used in this case. The
gdaemonvfs extension point will end up talking to the session bus
which is typically undesirable in a setuid context.
Implementing g_check_setuid() is interesting - whether or not we're
running in a privilege-escalated path is operating system specific.
Note that GTK+'s code to check euid versus uid worked historically on
Unix, more modern systems have filesystem capabilities and SELinux
domain transitions, neither of which are captured by the uid
comparison.
On Linux/glibc, the way this works is that the kernel sets an
AT_SECURE flag in the ELF auxiliary vector, and glibc looks for it on
startup. If found, then glibc sets a public-but-undocumented
__libc_enable_secure variable which we can use. Unfortunately, while
it *previously* worked to check this variable, a combination of newer
binutils and RPM break it:
http://www.openwall.com/lists/owl-dev/2012/08/14/1
So for now on Linux/glibc, we fall back to the historical Unix version
until we get glibc fixed.
On some BSD variants, there is a issetugid() function. On other Unix
variants, we fall back to what GTK+ has been doing.
Reported-By: Sebastian Krahmer <krahmer@suse.de>
Signed-off-by: Colin Walters <walters@verbum.org>
Also, make it possible to get a 'new ref' on a datalist member
in a race-free way.
This is useful when using object data in thread-safe libraries.
https://bugzilla.gnome.org/show_bug.cgi?id=682849
Because it now handles EINTR. And we should do so. While most people
use Linux, which tries very hard to avoid propagating EINTR back up
into userspace, it can still happen.
https://bugzilla.gnome.org/show_bug.cgi?id=682833
I'd like to use GVariant as a data format in my userspace filesystem,
and having the actual bits be stable means I can reliably compute
cryptographic checksums.
This updated patch removes vardict checks, because Ryan wants the
flexibility to change them in the future.
https://bugzilla.gnome.org/show_bug.cgi?id=673012
This function is causing an insane amount of wasted time on some
real-world profiles and it's pretty useless since we already have
GVariantType (as a type different from a string) for the purpose of
static type safety.
Disable it for now. We can possibly turn this back on again if we solve
bug #544026.
https://bugzilla.gnome.org/show_bug.cgi?id=679835
A parent source holds refs on its children, so if the child source is
destroyed, we need to drop that ref. Fix, and reorganize to make this
all more obvious.
https://bugzilla.gnome.org/show_bug.cgi?id=682560
If a context was freed with sources still attached, those sources
correctly got destroyed, but the corresponding GSourceList structs
were being leaked.
https://bugzilla.gnome.org/show_bug.cgi?id=682560
set_mime_type, set_is_private, add_group, set_groups, set_icon, etc
all added metadata before using it. If set_app_info was called before
any of those it would crash when trying to access the metadata.
For some time now people have been asking for a way to check for type
compatibility between GVariant instances and format strings. There are
several APIs inside of GLib itself that would benefit from this.
This patch introduces a way to do that.
The size of the local_data arrray is too large. It should not be
multiplied by the sizeof guint.
The memcpy of profile_data to local_data later will only fill a part of the
array.
Spotted with the PVS-Studio static analyzer
https://bugzilla.gnome.org/show_bug.cgi?id=681501
Running with automake-1.11.1, a couple fixes are needed
for CLEANFILES when gtk-doc is not installed.
(Found with Amazon Linux AMI release 2012.03)
https://bugzilla.gnome.org/show_bug.cgi?id=682067
-glib/gmarkup.c: Use G_VA_COPY() instead of va_copy() as va_copy() may not
be universally available.
-gio/gtestdbus.c: Include io.h on Windows for close()
Add a variant of g_markup_collect_attributes() which will
ignore unknown attributes (such as those from different XML
namespaces) when parsing markup, rather than returning
G_MARKUP_ERROR_UNKNOWN_ATTRIBUTE as g_markup_collect_attributes()
does.
Patch by Philip Withnall,
https://bugzilla.gnome.org/show_bug.cgi?id=665634
GThreadPool defaulted to 0 for max_unused_threads (meaning thread-pool
threads would exit immediately if there was not already another task
waiting for them), and 0 for max_idle_time (meaning unused threads
would linger forever, though this is only relevant if you changed
max_unused_threads).
However, GIOScheduler changed the global defaults to 2 and 15*1000,
respectively, arguing that these were more useful defaults. And they
are, so let's use them.
https://bugzilla.gnome.org/show_bug.cgi?id=661767
g_source_get_context() was checking that the source wasn't destroyed
(since a source doesn't hold a ref on its context, and so
source->context might point to garbage in that case). However, it's
useful to be allowed to call g_source_get_context() on a source that
is destroyed-but-currently-running.
So instead, let g_source_get_context() return the context whenever
it's non-NULL, and clear the source->context of any sources that are
still in a context's sources list when the context is freed. Since
sources are only removed from the list when the source is freed (not
when it is destroyed), this means that now whenever a source has a
non-NULL context pointer, then that pointer is valid.
This also means that g_source_get_time() will now return-if-fail
rather than crashing if it is called on a source whose context has
been destroyed.
Add tests to glib/tests/mainloop to verify that g_source_get_context()
and g_source_get_time() work on destroyed sources.
https://bugzilla.gnome.org/show_bug.cgi?id=661767
Verify that
- g_source_get_time() does not change within a single callback
(even if the real time does)
- g_source_get_time() does not change between different callbacks in
the same mainloop iteration
- g_source_get_time() does change between iterations if the real
time did.
https://bugzilla.gnome.org/show_bug.cgi?id=661767
g_utf8_strup() tries to call setlocale() before starting to compute
the length of its first argument. Calling setlocale() can return NULL
(as specified in the man page), and obviously that happens on android.
https://bugzilla.gnome.org/show_bug.cgi?id=680704
The old (length) annotation actually wasn't being read. Changing
it to an array was telling g-i that it was an array of utf8, which
is clearly not true.
We *could* add (element-type guint8), but that would change it to a
byte array, as opposed to the original utf8 version.
Just removing the annotation should bring us back to where we
were, which was fine.
https://bugzilla.gnome.org/show_bug.cgi?id=680310
Bug 680074 shows that we may end up in situations where only
some of the xlocale functions we need are available. Rather than
trying to find the minimal set of required functions for each
use, define a global USE_XLOCALE and only use any xlocale functions
if we have a full set.
Child sources are supposed to be blocked when their parents are, so
when adding a source to a blocked source, block the child too. Fixes a
warning when unblocking the parent.
On Windows, GetEnvironmentVariable() returns 0 for empty variables.
Checking GetLastError() == ERROR_ENVVAR_NOT_FOUND helps make a
difference between a variable that does not exist or an empty one
which should return "".
https://bugzilla.gnome.org/show_bug.cgi?id=679617
The current code create the strv array incorrectly, it is too big and
leaves invalid holes. This may result in crashes when freeing the
returned value.
https://bugzilla.gnome.org/show_bug.cgi?id=679617
Many (if not "almost all") programs that spawn other programs via
g_spawn_sync() or the like simply want to check whether or not the
child exited successfully, but doing so requires use of
platform-specific functionality and there's actually a fair amount of
boilerplate involved.
This new API will help drain a *lot* of mostly duplicated code in
GNOME, from gnome-session to gdm. And we can see that some bits even
inside GLib were doing it wrong; for example checking the exit status
on Unix, but ignoring it on Windows.
https://bugzilla.gnome.org/show_bug.cgi?id=679691
String validation was done by checking if the string was valid utf8 and
ensuring that the first non-utf8 character was the last character (ie:
the nul terminator).
No check was actually done to make sure that this byte actually
contained a nul, however, so it was possible that you could have a
string like "hello\xff" with length 6 that would correctly validate.
Fix that, and test it.
If GLIB_VERSION_MIN_REQUIRED or GLIB_VERSION_MAX_ALLOWED was defined
to a future value, we were essentially treating it as
GLIB_VERSION_0_0. Fix to treat it as being in the future instead.
https://bugzilla.gnome.org/show_bug.cgi?id=674898
The docs for GString should really mention GByteArray, and what makes
it different. Drop the comparison to Java which is dated and actually
inaccurate (because StringBuffer operates on Unicode).
While we're here, add g_string_free_to_bytes(), which further
complements the spread of GBytes-based API. For example, one can
create a buffer using GString, then send it off via
g_output_stream_write_bytes().
https://bugzilla.gnome.org/show_bug.cgi?id=677064
The Since tag for these was saying 2.28 but it was actually added in
2.31. It looks like all of the Since tags list stable version numbers
so this patch bumps that up to 2.32.
https://bugzilla.gnome.org/show_bug.cgi?id=679258
Since PCRE 8.00 it supports a variant of PCRE_NOTEMPTY that works
similarly except that it only applies to the start of the matched string
but permits empty matches further in.
g_regex_get_compile_get_compile_flags() and g_regex_get_match_flags()
were leaking PCRE flags that don't exist in the corresponding
public GRegexCompileFlags and GRegexMatchFlags; this change masks
these internal flags.
These flags override the compile option at match time. They use PCRE_BSR_ANYCRLF
and PCRE_BSR_UNICODE, resp., which make \R match only CR, LF and CRLF, or any
Unicode newline character or character sequences, resp.
