Instead of INCLUDES, which is deprecated in automake. Using AM_CPPFLAGS
also gives the hint that the -D argument should be a CPPFLAGS variable,
rather than CFLAGS.
I searched all files that mention g_test_run, and replaced most
g_print() calls. This avoids interfering with TAP. Exceptions:
* gio/tests/network-monitor: a manual mode that is run by
"./network-monitor --watch" is unaffected
* glib/gtester.c: not a test
* glib/gtestutils.c: not a test
* glib/tests/logging.c: specifically exercising g_print()
* glib/tests/markup-parse.c: a manual mode that is run by
"./markup-parse --cdata-as-text" is unaffected
* glib/tests/testing.c: specifically exercising capture of stdout
in subprocesses
* glib/tests/utils.c: captures a subprocess's stdout
* glib/tests/testglib.c: exercises an assertion failure in g_print()
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=725981
Reviewed-by: Colin Walters <walters@verbum.org>
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
If we call time(NULL), then do something (however trivial), then call
g_date_time_new_now_utc(), they do not necessarily share a seconds
value. Let's say the gmtime call takes 2ms. time(NULL) could
return xx:xx:23 when the time is actually xx:xx:23.999999, resulting
in the g_date_time_new_now_utc() happening at xx:xx:24.000001. This is
unlikely, but did happen to me in a parallel build:
GLib:ERROR:.../glib/tests/gdatetime.c:674:test_GDateTime_now_utc: assertion failed (tm.tm_sec == g_date_time_get_second (dt)): (23 == 24)
A similar argument applies to the rollover from xx:23:59.999999 to
xx:24:00, so comparing seconds with a 1s "fuzz" or a >= comparison
is not sufficient; and so on into higher-order fields.
I haven't seen the other tests that use _now() fail in the same way,
but they could.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=749080
Reviewed-by: Philip Withnall <philip.withnall@collabora.co.uk>
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
It's unhelpful to get an error saying that stderr didn't match a
desired pattern, or matched an undesired pattern, without also
telling you what *was* on stderr. Similarly, if a test subprocess
exits 1, there's probably something useful on its stderr that
could have told you why.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=748534
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Dan Winship <danw@gnome.org>
Unlike, say, g_variant_new(), which returns a floating reference.
g_variant_parse() returns a non-floating one, so must always have
g_variant_unref() called on the result.
Our signal handler calls write() on a pipe or an eventfd in order to
deliver the notification. It's unlikely, but this could fail, setting
errno. We even check the case that it fails with EINTR.
If it does set errno, then it has potentially blown away the value or
errno that the preempted code cared about (ie: if the signal arrived
shortly after a system call but before errno was checked).
Wrap the handler with code to save errno.
https://bugzilla.gnome.org/show_bug.cgi?id=741791
Fix a few typical problems, and also stop wrapping the inline definition
of g_steal_pointer in parens, since it is not necessary and it confuses
gtk-doc.
It was added after G_END_DECLS, outside the #ifdef G_PLATFORM_WIN32,
and inside a #ifndef __GTK_DOC_IGNORE__ block. So it was missing from
the doc.
https://bugzilla.gnome.org/show_bug.cgi?id=743661
• Clarify that GError** parameters are for the return of _newly
allocated_ GError*s.
• Clarify that errors may need to be checked for explicitly if the
return value of a function doesn’t reliably indicate them.
https://bugzilla.gnome.org/show_bug.cgi?id=741779
i.e. That calling g_timeout_add() from a thread other than the main one
probably doesn’t do what you want. Same for g_idle_add() and the
*_full() variants.
https://bugzilla.gnome.org/show_bug.cgi?id=741779
It was documented before, but wasn’t especially clear. Doing
if (X)
g_free (X);
is apparently quite a pervasive real-world anti-pattern, so perhaps it
could be documented more explicitly.
https://bugzilla.gnome.org/show_bug.cgi?id=741779
Just in case people have forgotten their basic algorithms course. Seen
in some pretty terrible code in the wild; hopefully mentioning the cost
in the documentation will make people think twice about using a counter
variable when iterating over a linked list.
https://bugzilla.gnome.org/show_bug.cgi?id=741779
It’s NULL iff free_segment is TRUE, so the annotation doesn’t quite
capture all the function definition, but is a safe over-estimate of the
return value’s nullability.
https://bugzilla.gnome.org/show_bug.cgi?id=719966
I love Emacs keyboard macros, used them to convert the list of
defines cleverly into a list of tests, then iterated and filled in
the necessary constructor arguments.
- It's not sufficient, there are other bare array types
like guint8, gdouble, etc.
- Other types like GVariant* always come as pointers, whereas
there's a rather fundamental distinction between "gchar" and
"gchar*" that has been signified to C programmers for 30+ years via
the '*' character, and we're hiding that.
https://bugzilla.gnome.org/show_bug.cgi?id=744747
The g_autoptr() being associated with the type name works out really
well for things like GHashTable. However, it's a bit more awkward to
associate with "gchar". Also because one can't use "char".
Similarly, there are a lot of other "bare primitive array" types that
one might reasonably use.
This patch does not remove the autoptr for "gchar", even though I
think it's rather awkward and strange.
Also while we're here, add a test case for the cleanup bits.
https://bugzilla.gnome.org/show_bug.cgi?id=744747
This would allow bindings to use _get_option_group() functions, which
would then allow them to use GOption parsing.
This also adds introspection annotations to
g_option_context_add_group(), g_option_context_set_main_group() and
g_option_context_get_main_group().
https://bugzilla.gnome.org/show_bug.cgi?id=743349
Despite linked lists being a fairly fundamental computer science
concept, some developers insist on using:
g_list_length (list) > 0
to determine whether a list is non-empty, rather than using:
list != NULL
Add a comment to the documentation for g_list_length() and
g_slist_length() pointing out the better alternative in the hope that it
will prevent some of this abuse.
https://bugzilla.gnome.org/show_bug.cgi?id=741024
gmem.h and gthread.h made use of the inline keyword, that is not available
on all compilers in C-mode, causing builds to break on such compilers.
Include glib/gutils.h which handles the inline issue, in place of
glib/gtypes.h if applicable, which is included quite early on by
glib/gutils.h.
https://bugzilla.gnome.org/show_bug.cgi?id=744190
We have a test that #includes our headers from a C++ program to make
sure we don't throw any errors or warnings as a result of that.
The new inline implementation of g_steal_pointer() does an implicit
conversion from (void *), which is not valid in C++.
Add a cast to avoid the problem.
Thanks to Ignacio Casal Quinteiro for the report.
This is particularly nice when used with g_autoptr(). See examples in
the docs.
This patch is based upon an idea (and original patch submission) from
Will Manley <will@williammanley.net>.
https://bugzilla.gnome.org/show_bug.cgi?id=742456
This is necessary as we are using _GLIB_AUTOPTR_TYPENAME and
_GLIB_AUTOPTR_FUNC_NAME in gtype.h for G_DECLARE_DERIVABLE_TYPE and
G_DECLARE_FINAL_TYPE, but _GLIB_AUTOPTR_TYPENAME and
_GLIB_AUTOPTR_FUNC_NAME expand to nothing on non-GCC, causing builds on
non-GCC to break, due to bad typedef and function definitions.
This patch defines a new private macro which does what is needed on GCC
builds and does nothing on non-GCC builds, thus fixing the build.
https://bugzilla.gnome.org/show_bug.cgi?id=743640
Add the missing 'none' argument to this macro in the non-GCC case. The
none parameter was added after the others and I forgot to update the
non-GCC case.
https://bugzilla.gnome.org/show_bug.cgi?id=743640
Add g_auto() and g_autoptr() as helpers for declaring variables with
automatic cleanup.
Add some macros to help types define cleanup functions for themselves.
Going forward it will be an expectation that people use this macro when
creating a new type, even if they do not intend to use the auto-cleanup
functionality for themselves.
These new macros only work on GCC and clang, which is why we resisted
adding them for so long. There exist many people who are only
interested in writing programs for these compilers, however, and a
similar API in libgsystem has proven to be extremely popular, so let's
expose this functionality to an even wider audience.
We ignore deprecation warnings when emitting the free functions, which
seems suspicious. The reason that we do this is not because we want to
call deprecated functions, but just the opposite: sometimes the free
function will be an _unref() function that is only AVAILABLE_IN newer
versions, and these warnings are also implemented as deprecation
warnings.
https://bugzilla.gnome.org/show_bug.cgi?id=743640
This adds a public API where one can use to see whether the running version
of Windows where the code is run is at least the specified version, service
pack level, and the type (non-server, server, any) of the running Windows
OS.
This API is done as:
-GetVersion()/GetVersionEx() changed in the way they work since Windows 8.1
[1][2], so a newer mechanism to check the version of the running Windows
operating system is needed. MSDN also states that GetVersion() might be
further changed or removed after Windows 8.1. This provides a wrapper for
VerfyVersionInfo() as well in GLib for most cases, which was recommended
in place of g_win32_get_windows_version() for more detailed Windows
version checking.
-Provides an OS-level functionality check, for those that we don't need to
venture into GetProcAddress(), and also to determine system API behavior
changes due to differences in OS versions.
Also added a note for the g_win32_get_windows_version() API that since the
behavior of GetVersion() which it uses, is changed since Windows 8.1, users
of the API should be aware.
[1]:
http://msdn.microsoft.com/zh-tw/library/windows/desktop/ms724451%28v=vs.85%29.aspx
[2]:
http://msdn.microsoft.com/zh-tw/library/windows/desktop/ms724451%28v=vs.85%29.aspxhttps://bugzilla.gnome.org/show_bug.cgi?id=741895
Include an example main() function, and include a link to the gettext
manual’s section on integrating gettext with build systems.
That should work as a complete reference for how to add i18n support to
an application.
https://bugzilla.gnome.org/show_bug.cgi?id=742972
Update config.h.win32.in and glibconfig.h.win32.in so that they will be
in-line with the ones that are produced with configure.ac, for use on
Windows builds.
Thanks to Philip Withnall for pointing out the changes needed to update
glibconfig.h.win32.in in bug 727829.
We should not advise people to cast the result of
g_hash_table_get_keys_as_array() to a type that looks suitable for use
with g_strfreev(). Advise to use (const gchar **) instead.
We intend to keep the list of poll records sorted by (integer) file
descriptor, but due to a typo we are actually keeping it sorted by
pointer address of the GPollFD.
Fix that.
https://bugzilla.gnome.org/show_bug.cgi?id=11059
It simplifies a little bit some code that inserts data relative to a
GList location, that might be NULL for the tail of the queue. A NULL
sibling is probably less useful for insert_after(), so it's more for
consistency with insert_before().
https://bugzilla.gnome.org/show_bug.cgi?id=736620
If a given fd is being polled by multiple sources, we used to pass it
multiple times to g_poll(), which is technically illegal (and not
supported by the select()-based fallback implementation of poll() in
gpoll.c), and also made it more likely that we'd exceed the maximum
number of pollfds.
Fix it to merge together "duplicate" GPollFDs. The easiest way to do
this involves re-sorting context->poll_records into fd order rather
than priority order. This means we now have to walk the entire pollrec
list for every g_main_context_query() and g_main_context_poll(),
rather than only walking the list up to the current max_priority.
However, this will only have a noticeable effect if you have tons of
GPollFDs, and we're already too slow in that case anyway because of
other O(n) operations that happen too often. So this shouldn't change
much (and the new poll API will eventually let us be cleverer).
Remove some win32-specific code which did the same thing (but was
O(n^2)).
https://bugzilla.gnome.org/show_bug.cgi?id=11059
We called getopt() to try to find out of the platform on which we are
running defaults to strict POSIX-style argument handling (ie: flags
following the first filename are considered as further filenames rather
than flags).
This is the default case on BSDs, for example. It is also the case on
GNU systems with the POSIXLY_CORRECT environment variable set.
Unfortunately many of our tools rely on being able to accept commandline
arguments in the non-strict ordering and the code for making these calls
is spread widely (for example in Makefile fragments invoking some of our
build tools).
For this reason we need to revert the getopt() check and only enable
strict POSIX mode in the case that the application explicitly opts into
it using the _set_strict_posix() API.
This also fixs a failure to build on Windows due to missing getopt().
https://bugzilla.gnome.org/show_bug.cgi?id=723160
With this patch it is fine to call g_hash_table_lookup and
g_hash_table_remove from destroy notification functions. Before
this could lead to an infinitie loop if g_hash_table_remove_all
was used.
https://bugzilla.gnome.org/show_bug.cgi?id=695082
Add a "posixly correct" mode to GOption to stop parsing arguments as
soon as the first non-option argument is encountered.
We determine the default value on the basis of duplicating the behaviour
of the system getopt() implementation (which we directly check the
behaviour of at runtime). On GNU systems this allows the user to modify
our behaviour using POSIXLY_CORRECT.
The user can change the value by g_option_context_set_strict_posix(),
which might be useful for some usecases of GOptionContext (as mentioned
in the doc string of this new function).
https://bugzilla.gnome.org/show_bug.cgi?id=723160
g_get_monotonic_time() and g_get_real_time() now always use different
clocks, so we cannot avoid correcting for their offset. Fixes failure
to time out on Mac OS X.
https://bugzilla.gnome.org/show_bug.cgi?id=738197
Internal allocation size (array->alloc) was being kept to 0 when a new
GByteArray was created from an already existing heap-allocated buffer.
Among other things, this was making g_byte_array_set_size() fully clear all
the buffer contents (not just the newly allocated memory) when
G_DEBUG=gc-friendly was being used...
if (G_UNLIKELY (g_mem_gc_friendly))
memset (array->data + array->alloc, 0, want_alloc - array->alloc);
https://bugzilla.gnome.org/show_bug.cgi?id=738170
If a GSource is created, *not* attached to a GMainContext, and then has
child sources added, dropping the last reference to the parent GSource
will leak its references to its child sources. Currently, child sources
are only unreffed when g_source_destroy() is called on the parent.
https://bugzilla.gnome.org/show_bug.cgi?id=737338
This ensures the uintptr_t type is defined on mingw-w64.
Fixes compile error:
make[4]: Entering directory
`/home/abuild/rpmbuild/BUILD/glib-2.42.0/gobject'
CC libgobject_2_0_la-gtype.lo
In file included from gtype.c:24:0:
../glib/valgrind.h: In function 'VALGRIND_PRINTF':
../glib/valgrind.h:5601:4: error: unknown type name 'uintptr_t'
uintptr_t _qzz_res;
^
https://bugzilla.gnome.org/show_bug.cgi?id=737143
Step up thread safety on g_source_set_name() to the same standard as all
other GSource functions: after we are attached to a main context, this
function should be threadsafe.
https://bugzilla.gnome.org/show_bug.cgi?id=736683
Document that one must not use the "by id" source APIs with non-existent
IDs. The real justification behind this restriction is that the reuse
of source ids makes it unsafe to call these functions unless you're
absolutely sure that the source exists and it belongs to you. If you
call one of these functions on a source that may already have been
removed then you run the risk of finding someone else's source (with
your reused id).
This also bails us out of a slightly tricky situation with respect to
the threadsafety of g_main_context_find_source_by_id(). The fact that
this function doesn't return a reference implies that its return value
cannot be safely accessed unless we already know for sure that a
reference is being held elsewhere (by example, by the main context
itself if we know that the source has not been removed). The function
itself, however, performs an access to the value, which could result in
a crash.
If we mandate that it is only valid to call this function on
known-to-exist source IDs then we dodge this problem.
https://bugzilla.gnome.org/show_bug.cgi?id=736683
This confused me for a while, because it isn't the same as D-Bus.
Like GVariant, the D-Bus serialization needs an out-of-band
endianness and type indicator, but unlike GVariant, serialized
D-Bus objects encapsulate their own length (often by starting with
a byte-count). This does come at some redundancy cost, so I can see
why the more efficient GVariant format does this the way it does;
but it's a difference between D-Bus and GVariant that seems worth
calling out.
It's also relevant for the designers of file or message-framing
formats: with D-Bus serialization it would be feasible to say "the file
starts with a little-endian D-Bus variant, followed by...",
but in GVariant you wouldn't be able to deserialize the variant
unless you either assume that it extends to end-of-file, or have
an explicit length.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=736975
Reviewed-by: Ryan Lortie
For the GPtrArray example, several variables declared on the same line
is harder to read and to work with (to move, remove or comment a single
variable declaration).
As an example, the core of gedit is in a private library
placed in %INSTALLDIR%/lib/gedit/libgedit.dll
Before this patch we would get %INSTALLDIR%/lib/gedit as the
installation package dir, while what we actually want is to get
%INSTALLDIR%
https://bugzilla.gnome.org/show_bug.cgi?id=733934
Practically no caller of these functions require atomic behaviour,
but the atomics are much slower than normal operations, which makes
it desirable to get rid of them. We have not done this before because
that would be a break of the ABI.
However, I recently looked into this and it seems that even if the
atomics *are* used for g_clear_* it is not ever safe to use this. The
atomics protects two threads that are racing to free a global/shared
object from freeing the object twice. However, any *user* of the global
object have no protection from the object being freed while in use,
because there is no paired operation the reads and refs the object
as an atomic unit (nor can such an operation be implemented using
purely atomic ops).
So, since nothing could safely have used the atomic aspects of these
functions I consider it acceptable to just remove it.
https://bugzilla.gnome.org/show_bug.cgi?id=733969
This reverts commit 7269d75321.
Adding G_STATIC_ASSERT() into a header file caused compilation
problems with at least one app (Anjuta). Reverting to keep
GNOME continuous testing running.
https://bugzilla.gnome.org/show_bug.cgi?id=730932
This code assumes that int is exactly 4 bytes, and that pointers
are either 4 or 8 bytes, on platforms with __ATOMIC_SEQ_CST.
In practice this is going to be true.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=730932
Since we are getting passed Unicode values these global vars
might not have the correct value. Instead always get the wide arguments
and convert them to utf8 to use them.
https://bugzilla.gnome.org/show_bug.cgi?id=733146
Detect the following two errors:
- attempting to unlock a mutex that is not locked
- attempting to clear a mutex that was not initialised or was
initialised but is still locked
Both of these are fatal errors. We avoid using g_error() here because
doing so would involve calls back into the GMutex code, and if things
are going off the rails then we want to avoid that.
https://bugzilla.gnome.org/show_bug.cgi?id=731986
If we have futex(2) then we can implement GMutex natively and gain a
substantial performance increase (vs. using pthreads).
This also avoids the need to allocate an extra structure in memory when
using GMutex or GCond: we can use the structure directly.
The main reason for the increase in performance is that our
implementation can be made more simple: we don't need to support the
array of options on pthread_mutex_t (which includes the possibility, for
example, of being recursive).
The result is a ~30% improvement in uncontended cases and a much larger
increase (3 to 4 times) in contended cases for a simple testcase.
https://bugzilla.gnome.org/show_bug.cgi?id=731986
When GLib had been told to expect message X, but then actually saw
message Y, it would log the "did not see expected message" error with
message Y's log level and domain, which makes no sense. Change it to
log with domain "GLib" and G_LOG_LEVEL_CRITICAL instead.
Also, include the expected domain in the error message, so that if
that's the reason why the expectation didn't match, you can tell that
from the error message.
Update glib/tests/testing.c for these changes; for all other test
programs in GLib and elsewhere, this change should not break any
existing tests, it should only improve the output on failure.
https://bugzilla.gnome.org/show_bug.cgi?id=727974
...so that builds of GLib on x64 Visual C++ can be restored, as the build
fails in line 449 of valgrind.h as it only supports MinGW/GCC for x64
Windows and simply will not build otherwise. Make the x64 Visual C++
builds compile again by defining NVALGRIND when GLib is being built for
Windows on x64 Visual C++.
https://bugzilla.gnome.org/show_bug.cgi?id=732465
- g_subprocess_launcher_spawn() and spawnv(): there is no other way
AFAIK to create a GSubprocess from a launcher. So these
functions are not "convenience helper".
- annotate optional arguments for g_shell_parse_argv().
- other trivial fix
https://bugzilla.gnome.org/show_bug.cgi?id=732357
Our internal call to g_io_channel_read_line_backend() may return
G_IO_STATUS_ERROR, in which case two things will be true:
- the GError will have been set (if appropriate)
- the &got_length return value may not have been set
Since it's our convention to leave 'out' parameters untouched in
exception cases, this is perfectly fine. Unfortunately,
g_io_channel_read_line(), in wrapping this internal function, always
promotes the length parameter, even in the case of error.
Stop doing that in order to avoid overwriting the callers's variable
with junk in the error case.
https://bugzilla.gnome.org/show_bug.cgi?id=731339
Move width table generation into the gen-unicode-tables.pl script. This makes
updating the tables automatic without the previously required manual editing
required to insert the tables in the right place of the source code.
memcmp() is declared by glibc as follows:
/* Compare N bytes of S1 and S2. */
extern int memcmp (const void *__s1, const void *__s2, size_t __n)
__THROW __attribute_pure__ __nonnull ((1, 2));
despite the fact that it is valid to call it with a null pointer if the
size is zero.
gcc 4.9.0 contains a new optimisation that sees that we pass a pointer
to this function and concludes that it certainly must not be null,
removing a later check and thereby causing a crash.
We protect the invocation of memcmp() with a condition to prevent gcc
from making this false assumption (arguably under wrong advice from
glibc).
The code in g_wakeup_signal() is currently correct: it writes a 64-bit
counter increment value if the FD is an eventfd, and writes an arbitrary
8-bit value if using a normal pipe.
However, the reasoning behind these buffer sizes is not clear, and the
mismatch between the allocated buffer size and the length passed to
write() in the pipe case could be mistaken for a bug.
Coverity issue: #1159490https://bugzilla.gnome.org/show_bug.cgi?id=732002
clang defines the macro that we use to test for GCC's extension support
for C11 atomics, but doesn't define the extension in the same way.
Check for clang and disable the macros again if we find it.
https://bugzilla.gnome.org/show_bug.cgi?id=731513
A static analyzer flagged the g_file_get_contents() call as not
checking its return value. While the code here is actually correct,
it's verbose at best.
I think the "goto out + cleanup" code style is substantially cleaner,
less error prone, and easier to read. It also will pacify the static
analyzer.
https://bugzilla.gnome.org/show_bug.cgi?id=731584
Give compiler a hint that these should be inlined,
which doesn't seem to happen by default with -O2.
Yields 5% speedup in artificial benchmarks, and
1% speedup in a real-world test case doing a lot
of mutex locking and unlocking.
https://bugzilla.gnome.org/show_bug.cgi?id=730807
GCC does not yet support ISO C11 atomic operations, but it has
compatible versions available as an extension. Use these for load and
store if they are available in order to avoid emitting a hard fence
instruction (since in many cases, we do not need it -- on x86, for
example).
For now we use the fully seqentially-consistent memory model, since
these APIs are documented rather explicitly: "This call acts as a full
compiler and hardware memory barrier".
In the future we can consider introducing new APIs for the more relaxed
memory models, if they are available (or fall back to stricter ones
otherwise).
https://bugzilla.gnome.org/show_bug.cgi?id=730807
- GSubprocessLauncher exists since 2.40, not 2.36
- more logical order for g_markup functions
- fix short description of GMarkup
- GMarkupParser: specify that some parameters are NULL-terminated.
- g_string_new (NULL); is possible.
- other trivial fixes.
https://bugzilla.gnome.org/show_bug.cgi?id=728983
This testcase tests that short option arguments are
not erroneously added to the remaining argument array
when g_option_context_set_ignore_unknown_options is
called.
https://bugzilla.gnome.org/show_bug.cgi?id=729563
After a call to g_option_context_set_ignore_unknown_options(context, TRUE),
the values of short options were included in the array returned by a
G_OPTION_REMAINING option.
https://bugzilla.gnome.org/show_bug.cgi?id=729563
These did show up in the html. Since symbol names are checked for a
trailing plural s when generating the docs, the links stay functional
after removing these comments.
https://bugzilla.gnome.org/show_bug.cgi?id=728380
The block size wasn’t configured before, so calling g_hmac_new() with
G_CHECKSUM_SHA512 would hit a g_assert_not_reached() and explode.
Implement G_CHECKSUM_SHA512 and add unit tests for HMACs with SHA-256
and SHA-512 using the test vectors from RFC 4868.
https://bugzilla.gnome.org/show_bug.cgi?id=724741
There's no reason to check the length of @str in g_str_has_prefix(),
since if it's shorter than @prefix, the strncmp() will fail anyway.
And besides making the function less efficient, it also breaks code
like:
if (buf->len >=3 && g_str_has_prefix (buf->data, "foo"))
...
which really looks like it ought to work whether buf->data is
nul-terminated or not.
https://bugzilla.gnome.org/show_bug.cgi?id=727890
Rather than having special code in gsocket.c, handle Winsock errors
along with other Win32 errors in gioerror.c
Also, reference g_win32_error_message() from the
g_io_error_from_win32_error() docs, and update the
g_win32_error_message() docs to clarify that it works with Winsock
error codes too.
This means that the test can't build on Windows (and we do want it there).
This will be properly resolved with bug 725266, but let's not block the
build before then.
https://bugzilla.gnome.org/show_bug.cgi?id=724859
For now, we are mainly interested in G_MARKUP_TREAT_CDATA_AS_TEXT.
This commit makes markup-parse look for expected output files with
the extension .cdata-as-text in addition to .expected, and compares
the output of parsing with G_MARKUP_TREAT_CDATA_AS_TEXT against
them. markup-parse --cdata-as-text foo.gmarkup can be used to produce
such expected output.
Simplify our tracking of issued source id integers and fix some bugs.
Previously the source's id was remove from the 'used' table from
source_remove_from_context() which was also called if the source
priority was changed (in which case it would never be added back to the
table). The source id could be reissued in that case.
In the new approach, we just always keep a hash table of sources, by
source id. This simplifies the logic and will also allow us to improve
performance of g_main_context_find_source_by_id() which is called in some
fairly common cases, such as g_source_remove(). These improvements will be in
the following commits.
https://bugzilla.gnome.org/show_bug.cgi?id=724839
88182d375e caught this issue in
g_async_queue_timed_pop() but failed to fix the same bug in the _unlocked()
variant.
This is only a problem on 32bit systems. On 64bit systems, the tv_sec
in a timeval is already 64 bits, so no overflow occurs.
https://bugzilla.gnome.org/show_bug.cgi?id=722604
Clarify that _add_poll() _remove_poll() _add_unix_fd(),
_modify_unix_fd(), _remove_unix_fd(), _query_unix_fd(),
_set_ready_time(), _add_child_source() and _remove_child_source() are only
intended to be used by the implementation of a particular GSource -- not its
consumers.
https://bugzilla.gnome.org/show_bug.cgi?id=724707
g_main_context_acquire() mentions that you must have called it before
you make any calls to _prepare(), _query(), _check() or _dispatch().
For emphasis, add a note on each of those functions pointing back to the
fact that you must have called _acquire() before using them.
Due to its unusual interface, I suspect that nobody is using
g_main_context_wait() but there is no way to know.
Add a critical notice that will be displayed if anyone calls the
function, asking them to file a bug with us.
We'll let this go out with the 2.40 release and see if we get a response
before we proceed with actually breaking the functionality.
Make sure this call succeeds, aborting if it doesn't
This will prevent people from having to waste time chasing down the problems
that would otherwise be caused by this silent failure.
We now depend on CLOCK_MONOTONIC, but it's possible that people may
attempt to run GLib on systems where it isn't supported at runtime.
Check the return value of clock_gettime() and abort() if it fails in
order to save these people from wasting time on debugging a tricky
issue.
https://bugzilla.gnome.org/show_bug.cgi?id=670144
Add a note to the documentation that child sources cannot have their priority
changed independently from their parent. Add a g_return_if_fail() to the
public API in order to enforce this.
This was already a reality due to the check in
g_source_set_priority_unlocked(), but it was never explicitly documented.
https://bugzilla.gnome.org/show_bug.cgi?id=724706
Add a new function, g_str_to_ascii() that does locale-dependent ASCII
transliteration of UTF-8 strings.
This function works off of an internal database. We get the data out of
the localedata shipped with glibc, which seems to be just about the best
source of locale-sensitive transliteration information available
anywhere.
We include a update script with this commit that's not used by anything
at all -- it will just sit in git. It is intended to be run manually
from time to time.
https://bugzilla.gnome.org/show_bug.cgi?id=710142
We've had a relatively rocky path with g_cond_wait_until() on systems
that either don't support pthread_condattr_setclock() or where
g_get_monotonic_time() is not based on CLOCK_MONOTONIC (ie: Android and
Mac OS).
Fortunately, both of these platforms seem to share
pthread_cond_timedwait_relative_np() which allows us to implement
g_cond_wait_until() without races.
With this patch, we now require that one of pthread_condattr_setclock()
or pthread_cond_timedwait_relative_np() exists. A quick look around
suggests that this is true for all platforms that we care about.
This patch removes our use of pthread_cond_timedwait_monotonic() and
pthread_cond_timedwait_monotonic_np() which were Android-only APIs.
https://bugzilla.gnome.org/show_bug.cgi?id=673607
We now assume the existence of clock_gettime() and CLOCK_MONOTONIC as
specified by POSIX.1-2001. This means that we always return truly
monotonic time, which will prevent problems in the case that the user
changes the time.
Mac OS doesn't have clock_gettime() but it does have
mach_absolute_time(), so we can use that there.
We keep our Windows case as well (although we should simplify it once XP
hits EOL later this year).
This patch removes the fallback to gettimeofday() in case of missing
clock_gettime(). We no longer have any way to test this codepath and
therefore it must go.
This patch also restructures the #ifdef a bit so that we repeat the
entire function definition inside of #ifdef instead of just the entire
body of one function.
https://bugzilla.gnome.org/show_bug.cgi?id=724687
g_assert_true(), g_assert_false(), g_assert_null(), and
g_assert_nonnull() simply printed out the expression they were
checking, without any further explanation of what went wrong. (In
particular, "g_assert_true(x)" and "g_assert_false(x)" would both
print the same thing on failure.) Add a little bit more context.
https://bugzilla.gnome.org/show_bug.cgi?id=724385
We have a configure.ac check for lib.exe that attempts to enable
creation of .lib files for our 5 public libraries. That has been broken
for a long time for two reasons:
1) the Makefiles hardcode 'lib' instead of 'lib.exe'
2) we dropped generation of .def files quite some time ago (except for
in gthread where we have the two-symbol file under version control)
Add new rules for creating .def files from dumpbin.exe (which you should
have if you have lib.exe) and fix the .lib rules to use lib.exe.
Add a bit of $(AM_V_GEN) all around, as well.
https://bugzilla.gnome.org/show_bug.cgi?id=722033
Since we are no longer using sgml mode, using /* */ to
escape block comments inside examples does not work anymore.
Switch to using line comments with //
If we used a non-positive pid, we'd call waitpid(that_pid, ...)
which is exactly the situation this function can't deal with.
On Windows, GPid is a HANDLE (pointer), so I don't think the same thing
applies.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=723743
Reviewed-by: Ryan Lortie
In particular, it is not incorrect to g_return_if_fail (..., FALSE)
in a function returning a "success" gboolean and a GError: "failure to
meet the preconditions is an error" takes precedence over the
GError documentation's guarantee that the error will be set on failure.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=660809
Reviewed-by: Emmanuele Bassi
Since all element markup is now gone from the doc comments,
we can turn off the gtk-doc sgml mode, which means that from
now on, docbook markup is no longer allowed in doc comments.
To make this possible, we have to replace all remaining
entities in doc comments by their replacement text, & -> &
and so on.
We are a bit too aggressive about freeing memory in strv mode. Only
free it in the case that we actually set the pointer to NULL.
Uncovered by the GApplication tests.
Slightly expand on the documentation about casting varargs when
constructing GVariants, and link to it from all the functions where it’s
a necessary consideration.
Add an example of passing flags to a ‘t’ type variable (guint64).
Assuming the flags enum does not have many members, the flag variable
will be 32 bits wide, and needs an explicit cast to be passed into
g_variant_new() as a 64-bit value.
https://bugzilla.gnome.org/show_bug.cgi?id=712837
We need to re-get the size of tzi.DaylightName before we call
RegQueryValue() because the buffer might not have enough room to hold the
value for tzi.DaylightName that would be acquired by RegQueryValueExA(),
even though the size of tzi.DaylightName and tzi.StandardName is the same.
This is a pitfall of RegQueryValue()[1] as not doing this can result in an
ERROR_MORE_DATA (234) failure, causing the acquisition of tzi.DaylightName
to fail.
This will fix the gdatetime/equal test, amongst some other tests in
gdatetime, at least on certain non-English version of Windows.
[1]: http://social.msdn.microsoft.com/Forums/vstudio/en-US/84f90854-e90c-4b63-8fc1-655a0b4645fd/regqueryvalueex-returns-errormoredatahttps://bugzilla.gnome.org/show_bug.cgi?id=719344
Adds some code examples how functions can be used. Adds a hint
to look at GQueue if access to the start and the end of the list
is required.
applying comments from Emmanuele Bassi and adds some more
improvements to clarify how functions should be used.
https://bugzilla.gnome.org/show_bug.cgi?id=683388
GLib has a pervasive assumption that function and data pointers are
basically interchangeable, which is true in all modern ABIs,
but not actually guaranteed by ISO C. If someone tries to use GLib on a
platform where function and data pointers are different sizes, fail early.
https://bugzilla.gnome.org/show_bug.cgi?id=688406
It is possible (but unlikely) that there will be a non-empty list of
pending dispatches when we remove the last ref from a GMainContext.
Make sure we drop the refs on the sources appropriately.
Add a (now-working) testcase that demonstrates how to trigger the issue.
https://bugzilla.gnome.org/show_bug.cgi?id=139699
Add a note to the overview documentation for GOptionContext about why
you need to be careful about argv encoding on UNIX and about why you
should avoid argv entirely on Windows. Mention some possible
alternative approaches, including a code example.
https://bugzilla.gnome.org/show_bug.cgi?id=722025
This returns the command line in GLib filename encoding format (ie:
UTF-8) for use with g_option_context_parse_strv().
This will allow parsing of Unicode commandline arguments on Windows,
even if the characters in those arguments fall outside of the range of
the system codepage.
https://bugzilla.gnome.org/show_bug.cgi?id=722025
Add another difference to the freshly-added g_option_context_parse_strv:
now, on Windows, its arguments on to be in UTF-8 instead of the argv[]
encoding (from the system codepage).
The documentation teases g_win32_get_command_line() which is a new
GLib-filename-encoding-based function that will be added in a following
commit.
https://bugzilla.gnome.org/show_bug.cgi?id=722025
Use the new g_option_context_parse_strv() to patch up some leaks in some
insufficiently-argv-emulating testcases in option-context.c.
This gives some test coverage of the new function while also making
option-context now leak-free.
https://bugzilla.gnome.org/show_bug.cgi?id=721947
Add g_option_context_parse_strv() that obeys the normal memory conventions for
dealing with a strv instead of assuming that we're dealing with the 'argv'
parameter to main().
This will help for using GOptionContext with GApplication.
https://bugzilla.gnome.org/show_bug.cgi?id=721947
The names of the month (and abbreviations) are specific to the Windows
system locale, so we need to use SetThreadLocale() to set the locale of
the running program to en-US so that it will parse "March" and "Sept" etc.
correctly.
https://bugzilla.gnome.org/show_bug.cgi?id=719344
Windows will not allow one to write to a temp file opened by g_mkstemp()
by opening another fd associated with it before one closes the fd that
is returned by g_mkstemp(), which will cause the test_save test to fail.
Fix this by using a variable to store the fd from g_mkstemp() and checking
it, and call close() on that variable before attempting to call
g_key_file_save_to_file() on the temp file as that will attempt to open
another fd (which would not work) associated with that temp file.
https://bugzilla.gnome.org/show_bug.cgi?id=719344
Fix some races introduced in be2c7b83c4
while keeping the property that multiple handlers for the same unix
signal all get dispatched.
Also fix the behaviour of the source checking for pending signals when
it's created. No matter what we do here (clear the pending flag or not)
there is something that can go wrong.
If we clear the flag, we may prevent other sources from being
dispatched. If we don't clear it, we may end up dispatching the same
source twice (if we manage to dispatch it from its own thread before the
GLib worker has a chance to run).
Instead, run the full dispatch procedure when a new source is added. It
actually doesn't matter what thread this runs in since the lock is held.
https://bugzilla.gnome.org/show_bug.cgi?id=711090
The existing tests were accidentally using the same test data
twice. Fix that, and add another set of tests that exercise
the filename collation special cases.
g_time_val_from_iso8601 was attempting to parse strings
having only a date, but failed to actually set the timeval
despite returning TRUE. Since the docs state that the function
only parses strings containing a date and a time, just return
FALSE in this case.
Also remove an incomplete testcase for this behaviour that was
just checking the boolean return value, but not timeval.
This was a feature intended from the very beginning that somehow never
got written. It's a way to replace these sort of error messages out of
the GVariant parser:
1-2,10-15:unable to find a common type
with something in the style of the Vala compiler:
unable to find a common type:
[1, 2, 3, 'str']
^ ^^^^^
https://bugzilla.gnome.org/show_bug.cgi?id=715028
Most GErrors, such as GSomethingError, have a function to get
their quark that looks like g_something_error_quark(),
so bindings (such as gtkmm) would expect GVariantParseError
to have g_variant_parse_error_quark(). Instead this had
g_variant_parser_get_error_quark().
This deprecates the old function and adds the correct one,
making life easier for gtkmm (and maybe others).
https://bugzilla.gnome.org/show_bug.cgi?id=708212
Change g_test_run() to return 1 on failure (rather than the number of
failed tests), and 77 if all tests are skipped (since automake and
some other test harnesses recognize that status code).
Previously g_test_run() returned the number of failed tests, but this
behavior was not documented, and at any rate, prior to 2.39,
g_test_run() would normally not return at all if an error occurred.
https://bugzilla.gnome.org/show_bug.cgi?id=720263
Allow g_test_trap_subprocess() to be used in a simple cases by
rerunning the same test case itself. This is accomplished by
passing %NULL as the test case name.
https://bugzilla.gnome.org/show_bug.cgi?id=720236
Since we are already building a deprecated function for compatibility
reasons, we don't really need to see a warning when it uses another
deprecated GLib function.
Commit e53caad4 makes _g_log_abort() noreturn by calling abort()
unconditionally.
However, it is useful to be able to skip some log_abort() with a
debugger, to reach a point of interest. Revert back to previous
behaviour. Make g_assert_warning() noreturn by calling abort().
https://bugzilla.gnome.org/show_bug.cgi?id=711800
When calculating the array sizes in get_contents_stdio(), there is a
possibility of overflow for very large files. Rearrange the overflow
checks to avoid this.
The code already handled some possibilities of files being too large, so
no new GError has been added to handle this; the existing
G_FILE_ERROR_FAILED is re-used.
Found by scan-build.
https://bugzilla.gnome.org/show_bug.cgi?id=715164
This probably won’t crash, as it can only happen if (size == 0), but
add a check to be safe, and to shut up the static analyser.
This case can be reached with the following call:
gvs_read_unaligned_le(NULL, 0)
which can be called from:
gvs_tuple_get_child(value, index_)
with (value.data == NULL) and (value.size == 0).
Found by scan-build.
https://bugzilla.gnome.org/show_bug.cgi?id=715164
Don't attempt to insert environmental variables in the hash table during
the test listenv that is an empty string, as GetEnvironmentStringsW() also
returns special enviroment variables which have empty strings as their
variable names, at least on Windows 7 and 8.
https://bugzilla.gnome.org/show_bug.cgi?id=711047
Make some of the conversion functions a bit more friendly to allocation
failure.
Even though the glib policy is to abort() on allocation failure by
default, it can be quite helpful to return an allocation error for
functions already providing a GError.
I needed a safer g_utf16_to_utf8() to solve crash on big clipboard
operations with win32, related to rhbz#1017250 (and coming gdk handling
bug).
https://bugzilla.gnome.org/show_bug.cgi?id=711546
g_test_init() was calling _g_messages_set_exit_on_fatal() from
subprocesses, to make fatal log messages call _exit() rather than
abort(), but the function name is sort of confusing, and we don't
really need it anyway, since g_log() can just call g_test_subprocess()
instead and decide for itself.
Likewise, update g_assertion_message() to do the check itself, rather
than calling into gmessages to do it, and fix
g_assertion_message_expr() to also check whether it should exit or
abort. (Previously it always called abort(), although this didn't
actually matter since that was dead code until
test_nonfatal_assertions was added.)
https://bugzilla.gnome.org/show_bug.cgi?id=711800
g_test_set_nonfatal_assertions() was a no-op, because
g_assertion_message() wasn't actually checking the
test_nonfatal_assertions flag. Fix that and add a test.
Also, g_test_set_nonfatal_assertions() has to set test_mode_fatal to
FALSE as well, or else a failed assertion will cause the test program
to abort at the end of the failed test.
Also, belatedly add this and the new g_assert_* methods to the docs.
https://bugzilla.gnome.org/show_bug.cgi?id=711800
g_array_remove_range and g_byte_array_remove_range return
a pointer to the array, g_ptr_array_remove_range returns
void. Since it is pretty harmless, make it return the array
too.
https://bugzilla.gnome.org/show_bug.cgi?id=159528
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
