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.
commit 35066ed6c6b51317f49069f2564c547aa309f9f1 replaced entities, but
escaped the replacement text also inside literals, which resulted in the
escaping '\' to also appear in the documentation.
https://bugzilla.gnome.org/show_bug.cgi?id=727320
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
88182d375e13ae6519a288d5295220c83ca27e73 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.
