GUnixSocketAddress has some very strange logic for interpreting its
construct paramters. This logic behaves differently in these two cases:
g_object_new (G_TYPE_UNIX_SOCKET_ADDRESS,
"abstract", FALSE,
"address-type", ...,
NULL);
and
g_object_new (G_TYPE_UNIX_SOCKET_ADDRESS,
"address-type", ...,
NULL);
even though the default value for "abstract" is already FALSE.
Change the way the code works so that it is not sensitive to people
merely setting a property to its default value.
https://bugzilla.gnome.org/show_bug.cgi?id=698686
Install a public "gnetworking.h" header that can be used to include
the relevant OS-dependent networking headers. This does not really
abstract away unix-vs-windows however; error codes, in particular,
are incompatible.
gnetworkingprivate.h now contains just a few internal URI-related
functions
Also add a g_networking_init() function to gnetworking.h, which can be
used to explicitly initialize OS-level networking, rather than having
that happen as a side-effect of registering GInetAddress.
https://bugzilla.gnome.org/show_bug.cgi?id=623187
There are apparently two incompatible ways of naming abstract sockets:
pad the sockaddr with 0s and use the entire thing as the name, or else
don't, and just pass a shorter length value to the relevant functions.
We previously only supported the former method. Add support for the
latter.
Also correctly handle "anonymous" unix sockaddrs (eg, the client side
of a connection, or a socketpair() socket), and add unix domain socket
support to the socket-client and socket-server test programs to make
sure this all works.
https://bugzilla.gnome.org/show_bug.cgi?id=615960
This is nice for some callers so they can report an error.
It is also required to support opional address types like
abstract paths for unix domain sockets.
Types and methods for dealing with IPv4 and IPv6 addresses (and UNIX
domain socket addresses under UNIX). This does not include code for
actual socket I/O.
Originally from "gnio". Much of the code was written by Christian
Kellner, Samuel Cormier-Iijima, and Ryan Lortie.
Part of #548466.
