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
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
The API design here is a bit awkward — the in/out flags argument should
actually have been an in flags argument and an out msg_flags argument.
Clarify that a bit in the documentation.
https://bugzilla.gnome.org/show_bug.cgi?id=751924
_wstat32i64() doesn't exist in msvcrt.dll. This doesn't cause a problem
on 32-bit Windows because mingw-w64 #defines _wstat32i64 to _wstati64,
but on 64-bit Windows we get a link error.
In addition, _wstat32i64() takes a struct _stat32i64 *, but
GLocalFileStat is #defined to struct _stati64, which is not the same
type on 64-bit Windows.
Fix by using _wstati64().
https://bugzilla.gnome.org/show_bug.cgi?id=749161
Update the notes that this is also used for Visual Studio 2015 support,
and correct the MSVC_VER_LONG for MSVC 2015, which is 14, not 2015.
Also add a note that this can be used for other projects that have
Visual Studio build support.
Add a note stating that this script can be copied for use to replace
strings in files when necessary, such as replacing autotools variables
in non-autotools builds, such as Visual Studio builds.
