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.
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
