We need to have these in BUILT_SOURCES so that 'make' knows to generate them
before attempting to compile other .c files in the same directory (since some
of these files include the header).
Should fix up remaining issues about partial versions of this file being
included under parallel builds.
https://bugzilla.gnome.org/show_bug.cgi?id=725891
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
Add a test for GSubprocess to test setting, unsetting and inheritance of
environment variables. Use communicate() to give it a bit more of a
workout as well.
https://bugzilla.gnome.org/show_bug.cgi?id=725651
On the splice for stdout or stderr completing, GSubprocess calls
_slice_finish() to collect the result.
We assume that a zero return value here means failure, but in fact this
function returns a gssize -- the number of bytes transferred, or -1 for
an error.
This causes GSubprocess to mistakenly think that it has an error when it
actually just has an empty buffer (as would be the case when collecting
stderr from a successful command).
Check for -1 instead of FALSE to detect the error.
https://bugzilla.gnome.org/show_bug.cgi?id=724916
Add the basename from the first component of the Exec line to the list of
strings to search for via g_desktop_app_info_search().
We treat Exec as a fairly strong match -- just below the visible name.
Add a testcase to make sure everything is working OK.
https://bugzilla.gnome.org/show_bug.cgi?id=725023
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
Visual C++ is quite zealous about checking against the types used in the
initializing of array of structures, even up to Visual C++ 2013. Fix this
by splitting up the initializing steps.
https://bugzilla.gnome.org/show_bug.cgi?id=724609
There is no longer any code left in the check/prepare functions on UNIX,
so put %NULL in the GSourceFuncs vtable.
This also allows us to simplify some logic.
https://bugzilla.gnome.org/show_bug.cgi?id=724707
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
We are reusing the GPollFD.revents field of the source to store a
temporary value. Use a local variable for that instead.
This is a refactor to make the next commit easier to understand.
https://bugzilla.gnome.org/show_bug.cgi?id=724707
Now that GCancellable's GSource is based on _set_ready_time() instead of
an fd, we should use it as a child source, instead of forcing the
creation of the fd and adding it as a poll.
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
