* memleak: ipc_socket: properly dispose local-scoped strndup values
Leaking memory was only possible when using filesystem sockets (see
use_filesystem_sockets function) and either:
- client is deliberately disconnecting from a server (continued run
imposes a risk of exhausting memory)
- server is deliberately disconnecting from its client (ditto, but
more substantial risk due to the common shared-resource nature
of the server)
Signed-off-by: Jan Pokorný <jpokorny@redhat.com>
* memleak: ipc_socket: properly dispose inter-function strdup values
Leaking memory was only possible when the server accepted the client,
but didn't get (or was too shy) to talk to it prior to proceeding with
a disconnect.
Signed-off-by: Jan Pokorný <jpokorny@redhat.com>
* ipc_socket: care to explain what's going on with file name inference
Related to the code parts at hand, there was an investigation/fix in
the past, initiated by "make check" failure on FreeBSD 9 [rhbz#1256701].
Unfortunately, not only the magic constant being modified was not
explained in 1908e6c, but (one can derive because of a lack of solid
background of what's going on here, which might have caused that),
it was modified incorrectly at one instance (see also [PR165 comment]),
which was then reinstated in 7ebcb3d.
So, finally de-mystify those magic constants. Also break the symmetry
between the client/server further with depending on the canonical
"request socket" alias at the server side (the former worked equally but
it was unnecessarily confusing and there's a risk this artificial alias
will get removed in the future).
[rhbz#1256701] https://bugzilla.redhat.com/1256701
[PR165 comment] https://github.com/ClusterLabs/libqb/issues/165#issuecomment-142949541
Signed-off-by: Jan Pokorný <jpokorny@redhat.com>
41ae3e1267