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
The environment variable DISPLAY makes sense only for X11, it should
not be set in gio.
Beside, if the backend is not X11 but Wayland, forcing the value of
DISPLAY to the Wayland display will confuse the backend selection and
possibly crash the applications.
https://bugzilla.gnome.org/show_bug.cgi?id=754983
Commit a0cefc2217 introduced an unresolved
symbol, g_socket_send_message_with_timeout(), on win32. Windows
unfortunately isn’t clever enough to fill in the gaps and magic up the
implementation of that function from nowhere, so we had better do it
ourselves.
Factor the blocking behaviour out of g_socket_send_message() into a new
internal g_socket_send_message_with_timeout().
https://bugzilla.gnome.org/show_bug.cgi?id=756054
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
5d68947 factored out resuable items, but some of these are only for
*NIX builds, which will break the build on Windows. Fix this by
building these portions only when !G_OS_WIN32.
https://bugzilla.gnome.org/show_bug.cgi?id=756053
The value of g_socket_is_connected() gets stuck high if the GSocket is
shut down in two steps:
g_socket_shutdown (socket, TRUE, FALSE, NULL);
g_socket_shutdown (socket, FALSE, TRUE, NULL);
rather than one:
g_socket_shutdown (socket, TRUE, TRUE, NULL);
Fix that by tracking the connected status for the read half and the
write half of the connection separately.
https://bugzilla.gnome.org/show_bug.cgi?id=697907
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
set_auth_msg() was returning FALSE to indicate error, but all its
callers were expecting a negative return value to indicate error. This
was causing memory leaks for the GError, and errors to not be reported.
Coverity CID: 1325357
If --prefix is specified, marshaller_prefix is allocated and never
freed. It does not actually have to be allocated — just use the static
string from argv.
Coverity CID: 1325370
If the certificate constructor is called as:
g_tls_certificate_new_from_pem (data, length, NULL);
and PEM parsing fails for the private key, the function would have
continued to try and create a certificate using a NULL key_pem value,
which would have failed or crashed.
Use g_propagate_error() correctly to avoid this.
Coverity CID: 1325403
Remove some outdated references to an old example, and add a row in the
table of steps in object initialization for the GObjectClass.constructed
virtual method.
https://bugzilla.gnome.org/show_bug.cgi?id=754855
If an error in the underlying sendmmsg() syscall occurs after
successfully sending one or more messages, g_socket_send_messages()
should return the number of messages successfully sent, rather than an
error. This mirrors the documented sendmmsg() behaviour.
This is a slight behaviour change for g_socket_send_messages(), but as
it relaxes the error reporting (reporting errors in fewer situations
than before), it should not cause problems.
https://bugzilla.gnome.org/show_bug.cgi?id=751924
Add support for receiving multiple messages with a single system call,
using recvmmsg() if available. Otherwise, fall back to looping over
g_socket_receive_message().
This adds new API, g_socket_receive_messages(), and corresponding unit
tests.
https://bugzilla.gnome.org/show_bug.cgi?id=751924
In order to support per-operation timeouts on new API like
g_socket_receive_messages(), the internal GSocket API should use
timeouts rather than boolean blocking parameters.
(timeout == 0) === (blocking == FALSE)
(timeout == -1) === (blocking == TRUE)
(timeout > 0) === new behaviour
https://bugzilla.gnome.org/show_bug.cgi?id=751924
This complements the GOutputMessage struct. It will shortly be used for
adding a g_socket_receive_messages() function, but needs to be committed
first to allow some internal refactoring of GSocket.
https://bugzilla.gnome.org/show_bug.cgi?id=751924
This reverts commit 8e362161d9.
There is a fundamental difference between g_value_peek_pointer() and
g_value_get_pointer(), and it's not just complexity: the latter checks
if the GValue holds a pointer type, whereas the former doesn't.
https://bugzilla.gnome.org/show_bug.cgi?id=755922
Previously, GLib returned text/plain for empty files.
This is important because people may want to open empty (eg:
just-created) text files with the text editor.
An unintended side-effect of b6fc1df022
caused GLib to start returning application/octet-stream instead of
text/plain for these files.
This commit is essentially a revert of that commit, with a different
solution: we move the special-case up a bit in the function and
hard-code it to text/plain.
This change does not exactly maintain the old behaviour: previously, a
"fast" lookup would have returned application/octet-stream on an empty
file and now it will return text/plain. I consider this to be an
improvement (since we're returning better data) and don't expect it to
cause problems.
https://bugzilla.gnome.org/show_bug.cgi?id=755795
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
g_value_unset() only works with initialized value and will assert
if the GValue is zero-filled (or initialized with G_VALUE_INIT). Document
this behaviour and refer to g_value_clear() for a method that work on
both initialized and zero-filled GValue.
https://bugzilla.gnome.org/show_bug.cgi?id=755766
This change allow leaving a scope before g_value_init() has been
called. This would happen if you do:
{
g_auto(GValue) value = G_VALUE_INIT;
}
Or have a return statement (due to failure) before the part of
your code where you set this GValue.
https://bugzilla.gnome.org/show_bug.cgi?id=755766
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
