Declare that the previously-unused "..." argument to g_test_init() is
actually a NULL-terminated list of strings indicating testing options,
and add an option "no_g_set_prgname", which keeps g_test_init() from
calling g_set_prgname(). Then we can port glib/tests/option-argv0 to
use gtester, by passing that option.
https://bugzilla.gnome.org/show_bug.cgi?id=711796
In Windows development environments that have it, <unistd.h> is mostly
just a wrapper around several other native headers (in particular,
<io.h>, which contains read(), close(), etc, and <process.h>, which
contains getpid()). But given that some Windows dev environments don't
have <unistd.h>, everything that uses those functions on Windows
already needed to include the correct Windows header as well, and so
there is never any point to including <unistd.h> on Windows.
Also, remove some <unistd.h> includes (and a few others) that were
unnecessary even on unix.
https://bugzilla.gnome.org/show_bug.cgi?id=710519
Assume unix platforms support the original POSIX.1 standard.
Specifically, assume that if G_OS_UNIX, then we have chown(),
getcwd(), getgrgid(), getpwuid(), link(), <grp.h>, <pwd.h>,
<sys/types.h>, <sys/uio.h>, <sys/wait.h>, and <unistd.h>.
Additionally, since all versions of Windows that we care about also
have <sys/types.h>, we can remove HAVE_SYS_TYPES_H checks everywhere.
Also remove one include of <sys/times.h>, and the corresponding
configure check, since the include is not currently needed (and may
always have just been a typo for <sys/time.h>).
https://bugzilla.gnome.org/show_bug.cgi?id=710519
Assume all supported platforms implement C90, and therefore they
(correctly) implement atexit(), memmove(), setlocale(), strerror(),
and vprintf(), and have <float.h> and <limits.h>.
(Also remove the configure check testing that "do ... while (0)" works
correctly; the non-do/while-based version of G_STMT_START and
G_STMT_END was removed years ago, but the check remained. Also, remove
some checks that configure.ac claimed were needed for libcharset, but
aren't actually used.)
Note that removing the g_memmove() function is not an ABI break even
on systems where g_memmove() was previously not a macro, because it
was never marked GLIB_AVAILABLE_IN_ALL or listed in glib.symbols, so
it would have been glib-internal since 2004.
https://bugzilla.gnome.org/show_bug.cgi?id=710519
Remove workarounds for NeXTStep (last released in 1995), SunOS (1994),
HP-UX 9.x (1992) and 10.x (1995), OSF/1 / Digital UNIX / Tru64 UNIX
4.x (1999), and AIX 4.x (1999).
HP-UX 11 implements dlopen(), so dropping support for earlier versions
also lets us remove the HP-UX-specific gmodule-dld.
https://bugzilla.gnome.org/show_bug.cgi?id=710519
Since the initial addition of BeOS support in 1999, there has only
been one update to it (in 2005, and it wasn't even very big). GLib is
known to not currently build on Haiku (or presumably actual BeOS)
without additional patching, and the fact that there isn't a single
G_OS_BEOS check in gio/ is suspicious.
Additionally, other than the GModule implementation, all of the
existing G_OS_BEOS checks are either (a) "G_OS_UNIX || G_OS_BEOS", or
(b) random minor POSIXy tweaks (include this header file rather than
that one, etc), suggesting that if we were going to support Haiku, it
would probably be simpler to treat it as a special kind of G_OS_UNIX
(as we do with Mac OS X) rather than as its own completely different
thing.
So, kill G_OS_BEOS.
https://bugzilla.gnome.org/show_bug.cgi?id=710519
Skip the tests on inf/nan strings for the gvariant and strfuncs tests, and
skip the hex strings for the strtod tests in strfuncs as they are C99
features that are not yet supported by Visual C++ (even 2013). Use a
definition for NAN and INFINITY (that is also used in PyGObject) as
atof("NaN") and atof("Infinity") simply returns 0.0 (which is not a NAN)
in Visual C++ to fix the tests running there.
Also adapt to the format of g_ascii_formatd() when dealing with 1e99.
https://bugzilla.gnome.org/show_bug.cgi?id=711047
Use a Windows-style .bat script for the test_spawn_script() test, at least
when the code is built with Visual C++ (due to differences in how scripts
are written for shells and Windows cmd.exe), and account for Windows-style
line endings for that test too.
Let the MinGW builds (which are normally done in an MSYS BASH-style shell) continue to use the
*NIX-style script for that test.
https://bugzilla.gnome.org/show_bug.cgi?id=711047
Remove the parts about storing up the fd's in a data structure, but call
close() on the fd's. However, retain the _get_osfhandle() check on the
fd's when we iterate through the fd's as on fd values in the iteration may
well be invalid fd's. As a result, the invalid parameter handler is still
needed for newer Microsoft CRTs (8.0/2005+) for _get_osfhandle() to
make sure that the program does not abort when we check the validity of
fd's to be closed in the loop[1].
[1]: http://msdn.microsoft.com/en-us/library/ks2530z6%28v=vs.80%29.aspx
...Under various compilers when !G_DISABLE_CHECKS. Previously, the
messages that are logged differ depending whether GLib was built with GCC
or not. To simplify test cases, make all builds use a single output format
for g_return_if_fail(), g_return_val_if_fail(), g_return_if_reached(), and
g_return_val_if_reached(), by using the GCC-style format and replaceing
__PRETTY_FUNCTION__ with G_STRFUNC, so that it will work across various
compilers.
https://bugzilla.gnome.org/show_bug.cgi?id=711047
Even though we can't always make no-leak guarantees when g_warning()
in this case we're testing this behavior in tests, and it would be
good to be able to valgrind this.
https://bugzilla.gnome.org/show_bug.cgi?id=711751
Properly unref a pair of GSources in the unix-fd mainloop test.
valgrind was reporting these as 'still reachable' before (possibly due
to some residual pointers somewhere in memory), but when running with
G_DEBUG=cleanup they were properly reported as leaked.
Instead of having lots of 'if NULL then allocate' code segments for the
global GRand instance, move it to a single getter function that everyone
calls.
We were using g_mutex_init() to initialise a pair of mutexes in static
storage, but we should only do that for mutexes that are part of
allocated structures.
Include unistd.h only when G_OS_UNIX is defined (or when G_OS_WIN32 is not
defined). This will avoid including unistd.h unconditionally and/or
unecessarily, which may cause problems in certain scenarios, such as when
building the tests on Visual C++, which does not come with a unistd.h and
MinGW, where unistd.h is essentially a wrapper for io.h and process.h.
https://bugzilla.gnome.org/show_bug.cgi?id=711047
...and fix the test on non-English Windows, as gettext on Windows does
not honor LC_ALL = "C" (the default CRT behavior) but requires using
SetThreadLocale() to set the locale as it picks up the user's environment
and the thread's locale. Without doing so the g_format_size_for_display()
et al will display the translated message if the gettext translations have
been installed before, causing the test_format_size_for_display tests to
fail.
https://bugzilla.gnome.org/show_bug.cgi?id=711047
g_source_add_child_source() releases the context lock before attaching
child_source to context. And this causes trouble if parent source is
blocked and g_main_dispatch() manages to lock the context mutex and call
unblock_source() before child_source gets attached to context.
To fix this we call g_source_attach_unlocked() before releasing the
context mutex.
https://bugzilla.gnome.org/show_bug.cgi?id=711064
G_STRFUNC was checking __STDC_VERSION__ against the wrong value
(though it didn't actually matter, since __STDC_VERSION__ wasn't
defined in C90, so the check still only matched C99 and above anyway).
Make sure that if we ignore a tag then we also clear the attributes that
we already collected so that they don't end up on the next unignored tag
opening.
Also add some extra brackets for clarity (it doesn't make any difference
-- I just think it reads nicer this way).
https://bugzilla.gnome.org/show_bug.cgi?id=665634
Add a flag to GMarkupParserFlags to ignore qualified tags (along with
their contents) and attributes.
This will provide a nice way for some of our parsers (GDBus
introspection, GSettings schema, etc) to ignore additional tags that
users have added to their files, under a different namespace.
https://bugzilla.gnome.org/show_bug.cgi?id=665634
The code for dealing with </foo> and the second half of <foo/> was
largely duplicated. We can share a lot of it by using a common
function.
This slightly changes the behaviour of the parser under error
circumstances: previously the parser would deal with '<foo/}' by first
issuing the end_element callback and then flagging the error due to the
unexpected character. Now we will flag the unexpected character error
first, skipping the callback.
This behaviour change required modifying the testsuite.
https://bugzilla.gnome.org/show_bug.cgi?id=665634
Debug messages are meant to give insight into how a process is
proceeding, and are unpredictable in nature. They also often have
line numbers in them.
This patch ignores debug messages in g_test_assert_expected_messages().
https://bugzilla.gnome.org/show_bug.cgi?id=710991
We've added a g_critical() on failure to remove sources, so make sure we
expect to see that (instead of failing the test due to the unexpected
message).
https://bugzilla.gnome.org/show_bug.cgi?id=710724
In the case that g_key_file_get_(u)int64 fails to parse the integer,
make sure we free the string before returning.
Reported by Andrew Stone <astonecc@gmail.com>
https://bugzilla.gnome.org/show_bug.cgi?id=710313
Currently g_mem_gc_friendly is declared in both gmem.h and glib-init.h
files, we will have reports on each unit that include these two files.
This patch removes the redundant declaration from glib-init.h
Since g_mem_gc_friendly is related to gmem.h and was first declared in
this header which also exports it via glib.h, then declare it in gmem.h
Other files already include gmem.h: garray.c and gslice.c, no need to
change anything.
Signed-off-by: Djalal Harouni <tixxdz@opendz.org>
https://bugzilla.gnome.org/show_bug.cgi?id=710345
No need to include glib-init.h here. This was added by
commit 47444dacc0 but that commit did not make use of any its
exported symbols, so just remove it.
Signed-off-by: Djalal Harouni <tixxdz@opendz.org>
https://bugzilla.gnome.org/show_bug.cgi?id=710345
g_init_user_config_dir() is already declared as static in this gutils.c
file, so just remove the redundant declaration.
Signed-off-by: Djalal Harouni <tixxdz@opendz.org>
https://bugzilla.gnome.org/show_bug.cgi?id=710345
_g_charset_get_aliases() is already declared in gcharsetprivate.h
which was added by commit 4c2a659588, and gconvert.c includes
this gcharsetprivate header, so no need to declare it again.
Signed-off-by: Djalal Harouni <tixxdz@opendz.org>
https://bugzilla.gnome.org/show_bug.cgi?id=710345
Passing a NULL value to g_setenv() was never documented as working,
and in fact it worked on some platforms and crashed on others. Make it
g_return_if_fail() everywhere insted.
Also, remove some incorrect docs in g_environ_getenv() and
g_environ_setenv() that shouldn't have been copied from g_getenv() and
g_setenv(). And belatedly simplify the checks in g_unsetenv().
https://bugzilla.gnome.org/show_bug.cgi?id=704593
Add a pair of functions to make it easier to do simple string matching.
This will be useful for use with things like GtkSearchBar and will also
be the basis of the searching done by the (soon to appear)
g_desktop_app_info_search()
https://bugzilla.gnome.org/show_bug.cgi?id=709753
When the source id reaches G_MAXUINT (just prior to overflow), we
record the existing source ids to prevent reassigning them. As we are
about to assign G_MAXUINT to the triggering source, that id should be
added as well.
https://bugzilla.gnome.org/show_bug.cgi?id=710002
This stack exists only to answer the question of "what is the currently
dispatching source" and is handled in a way that makes it very clear
that we don't need to be using a linked list at all...
Just store the GSource directly.
Independently discovered (and same solution) by Phillip Susi.
https://bugzilla.gnome.org/show_bug.cgi?id=709113
Add a simple UNIX-only API that is used to create a GDir object from a
DIR* that is aquired using opendir() or fdopendir().
This makes it possible to use GDir with openat(), which in turn will
allow use of GDir in the existing GLocalFile implementation of
g_file_measure_disk_usage(), avoiding the current MSVC compatibility
problems there.
Also add an API similar to g_dir_open(), but without the GError handling
(since we want to create a better error message from inside of
glocalfile.c).
Thanks to Chun-wei Fan <fanchunwei@src.gnome.org> for portions of this
patch and for reviews.
https://bugzilla.gnome.org/show_bug.cgi?id=707787
We're testing for particular error messages, so we need to set to a C
locale to make sure we get the untranslated version.
Previously, this test set the LANG environment variable, but that's not
good enough if LANGUAGE is also set. The only way to ensure that
LANGUAGE is ignored is to disable l10n with LC_ALL=C.
Allow passing a NULL domain to g_test_expect_message(), and more
importantly, don't crash if a message with a NULL domain gets logged
while there is an expected message.
Implement gnulib strftime extensions for the '%z' numeric timezone
format. These are also supported and documented by GNU date(1):
%z +hhmm numeric time zone (e.g., -0400)
%:z +hh:mm numeric time zone (e.g., -04:00)
%::z +hh:mm:ss numeric time zone (e.g., -04:00:00)
%:::z numeric time zone with : to necessary precision (e.g., -04, +05:30)
https://bugzilla.gnome.org/show_bug.cgi?id=707151
Convert {glib,gobject,gio}/tests to use the automake TAP driver
and test harness instead of gtester. To do so, we add a glib-tap.mk
that provides the same interface as glib.mk, except for the
reporting and coverage testing functionality. Eventually, we may
want to replace glib.mk with it. I've not yet converted the
toplevel tests/ directory, since it mixes gtestutils tests with
other binaries.
https://bugzilla.gnome.org/show_bug.cgi?id=692125
When using test harnesses other than gtester (e.g. using TAP),
it can be suboptimal to have the very first failed assertion
abort the test suite.
This commit adds a g_test_set_nonfatal_assertions() that can
be called in a test binary to change the behaviour of most
assert macros to just call g_test_fail() and continue. We
don't change the behavior of g_assert() and g_assert_not_reached(),
since these to assertion macros are older than GTest, are
widely used outside of testsuites, and will cause compiler
warnings if they loose their noreturn annotation.
https://bugzilla.gnome.org/show_bug.cgi?id=692125
These are just like g_assert(), but using a different entry
point for the message, so we can repurpose them together
with the other assertion macros.
https://bugzilla.gnome.org/show_bug.cgi?id=692125
These two assertion macros are commonly used outside tests,
so we can't repurpose them, as we are going to do with the
other assertion macros in the following commits. This
change is in preparation for that.
https://bugzilla.gnome.org/show_bug.cgi?id=692125
This line was apparently causing build problems on Win64,
and since the only test involving the t_str variable was
already commented out, lets just take this out altogether.
https://bugzilla.gnome.org/show_bug.cgi?id=696970
The clang code analyzer needs to know that functions like g_error
g_critical an g_return_if_fail should be seen by the analyzer in the
same way as g_assert(). That is the analyzer should think they are
fatal.
https://bugzilla.gnome.org/show_bug.cgi?id=700268
The documentation for this function explicitly gives valid
ranges for the arguments and states that out-of-range arguments
will cause NULL to be returned. Only, the code didn't check
the ranges, and crashed instead. Fix that and add a testcase
for invalid arguments. It turns out that the test_z testcase
was providing invalid arguments and relied on g_date_time_new
to return a non-NULL value anyway, so this commit fixes that
testcase as well.
https://bugzilla.gnome.org/show_bug.cgi?id=702674
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
