If we fail to PeekMessage or PostMessage we should make sure
that the output parameter bytes_read/written is set 0 instead
of being left uninitialized. This fixes an assertion in the io
channel call where the following invariant is checked:
(status == G_IO_STATUS_NORMAL) || (read_size == 0)
Ignore trailing whitespace when reading boolean values. Currently it is
very easy to manually edit a keyfile to be:
[section]
key=true_
Where '_' is a space character. g_key_file_get_boolean will read this value as
false and this is hard for a user to detect (it will be reported in GError
as an invalid value).
Trailing whitespace is ignored for numbers for the same reason. This was
fixed in 7a45dde4fe64b4f6c6d3ebc54dfb54d106290e9d.
https://bugzilla.gnome.org/show_bug.cgi?id=664740
We were using the time() library call to get the current time from the
system in order to compare it to the time returned by
g_date_time_new_now().
Of course, we took care to ensure that the time (in seconds) didn't
change in the middle of this process by checking the before and after
value of the system time.
Unfortunately, the system time as measured by time() was being taken
from a less-accurate clock source than the time used by GDateTime. As a
result, we could have GDateTime already into the next second while the
"seconds" value of the time returned by time() was still in the last
one, even when checked "after".
Avoid the problem by using the same ultimate source for time --
g_get_real_time().
This is based on a similar patch from Iain Lane, but it uses
g_get_real_time() instead of g_get_current_time().
https://bugzilla.gnome.org/show_bug.cgi?id=754994
This function provides an O(1) check to determine if a sequence is empty.
Compare this to the two following alternatives to perform the same check.
O(h): if (0 == g_sequence_get_length (seq))
O(2h): if (g_sequence_get_begin_iter(seq) == g_sequence_get_end_iter(seq))
Where `h' is the height of the tree.
https://bugzilla.gnome.org/show_bug.cgi?id=756316
It updates it to the version c5d07ce91a8ad51591154450442fa4376441fdfa
As a difference with upstream we need to ensure:
* Include "g-gnulib.h" so the methods get the gnulib namespace.
* xsize.h uses G_MAXSIZE instead of SIZE_MAX and the methods are
marked as static inline.
* Some defines are named different from the ones in glib i.e
HAVE_LONG_LONG_INT is HAVE_LONG_LONG
All the unit tests pass properly with and without --enable-included-printf.
It has also been tested on Windows.
https://bugzilla.gnome.org/show_bug.cgi?id=756382
By default g_log_default_handler always assumes that stdout
and stderr are file descriptors 1 and 2. On Win32 this isn't
always the case as the win32 API functions AttachConsole and
freopen can be used to dynamically attach GUI applications to
a console and the file descriptors of stderr and stdout will
become different than 1 and 2.
Fix it by using fputs with the FILE directly instead of
using the file descriptors.
https://bugzilla.gnome.org/show_bug.cgi?id=692085
The VerifyVersionInfo() Win32 API has been deprecated in Windows 10, and
there is no direct replacement for it, except by using a lower-level
RtlGetVersion() that we aquire from the Windows DDK or from ntdll.dll.
Switch g_win32_check_windows_version() to use RtlGetVersion(), and
compare its results with the input parameters.
https://bugzilla.gnome.org/show_bug.cgi?id=756179
Some testutils external symbols are marked semi-internals, other
internals. It is not obvious what guarantees these symbols provide.
However, tests are now installable, and require the ABI stability
that glib provides for the rest of the symbols.
In my case, I would like to introduce g_assert* compat code for older
glib versions, and be able to use the so-called "internal" ABI.
I propose this change to the headers comments to explain the stability
guarantees. Removing the "internal" = you must not use this, in favor
of semi-internal = this is not documented.
https://bugzilla.gnome.org/show_bug.cgi?id=756077
In all these functions, group_name is guaranteed to be non-NULL by the
function preconditions, so there is no need to handle it as NULL when
building error messages. Remove some unnecessary string literals as a
result.
Coverity CID: 1325438–1325441
Copy the flatten-first logic from g_variant_get(), and for the same
reason: if the user is requesting a direct pointer access to a
tree-based child inside of argument to this function then that child
could disappear later.
Forcing serialisation means that the pointer will remain valid as long
as the passed-in instance exists, which is the usual expectation with
GVariant API.
https://bugzilla.gnome.org/show_bug.cgi?id=755374
Despite knowing about GError, there are multiple cases where developers
have still used traditional numeric error codes, and then got themselves
into a mess about bindability and generation of error messages.
Try and avoid this by including a brief paragraph on the benefits of
GError over EINVAL-style error codes.
https://bugzilla.gnome.org/show_bug.cgi?id=743011
This means that the top of the documentation can link forward to this
important section, and random people on the internet can link directly
to it on developer.gnome.org.
https://bugzilla.gnome.org/show_bug.cgi?id=743011
This reverts commit 662bf991c08b16dea8a36026243b311f6cdb17f1. It is not
a straight up revert because the old commit involved various long since
removed ChangeLog files and we'd end up mudding the patch.
The system_header GCC pragma is breaking warnings in the various
g_return_* macros; GCC stopped warning when using a macro with a return
value in a function that returns void, as well as when using a macro
with no return value in a function that has a non-void return value.
Suppressing this kind of warnings is not a good idea.
Other compilers are unaffected, even ones like Clang with a GCC
compatibility layer.
Given the fact that the original commit was added 14 years ago as a
workaround in the old days of GTK+ 1.2, I think it's safe to drop it.
https://bugzilla.gnome.org/show_bug.cgi?id=753310
For all test cases where the text length is given as -1, also
call g_utf8_validate() with the actual string length to exercise
the known-length case. Unknown-length and known-length validation
use different code paths, but most of the tests only exercised with
unknown-length parameter.
https://bugzilla.gnome.org/show_bug.cgi?id=754924
A recent change permitted some characters from range 0x80-0xbf as
would-be valid sequence starters for length 2, as long as
continuation characters were OK.
https://bugzilla.gnome.org/show_bug.cgi?id=738504
This code is used in the property notification path, so it
better be fast. This commit removes a g_return_if_fail check and
treats the common case of just a single data element better.
Apply the same optimization that was done for g_unichar_get_script
long ago: Use a quick check for the low end, and then remember the
midpoint of the last bsearch, since we're likely to be called for
characters that are close to each other.
This change made g_unichar_iswide disappear from profiles of the
gtk3-demo listbox example.
Store the (translated, UTF-8-encoded) error strings in a hash table to
avoid doing translation and (possibly) g_locale_to_utf8() in every
g_strerror() call.
https://bugzilla.gnome.org/show_bug.cgi?id=754788
Add a check to configure.ac for strerror_r, since we don't currently
require POSIX.1-2001 conformance in general. Add back a
plain-strerror() case as a fallback, and rearrange the glibc-vs-POSIX
strerror_r() branches.
Update the docs to not claim that "not all platforms support the
strerror() function" (we require C90), but still mention the UTF-8 and
always-valid-string benefits. (And make test_strerror() check that
last part.)
https://bugzilla.gnome.org/show_bug.cgi?id=754788
