When connect() fails in connect_unix() the path_ctx.fd is not
set to -1 after close(). When common_release() is executed due
to the error return from connect_unix() it calls close() a second
time.
There is no need to call close() from connect_unix(). Remove the
duplicate request.
This issue was reported by YASUOKA Masahiko.
Change-Id: I825e274cc7f12e50a8779a2b62ddb756817cdb52
When replying to a door call, if allocating the buffer using malloc()
fails, we return EAGAIN to the client to avoid it hanging, using a
variable on the stack. However in this case the code did not reset the
reply length, which would result in it reading past the end of the stack.
At the expense of a goto, this patch uses the same path for returning an
error as if it was generating by the application.
Also, ensure that reply->length is set to zero when returning an error;
it shouldn't affect the client as it will not read this in the event of
a non-zero return code, but it avoids leaking uninitialized memory.
The ucred_t argument must be initialized to zero otherwise it is assumed to
point to allocated memory. Also, the logic is inverted: getpeerucred()
returns zero on success, not failure.
We turn on a few extra warnings and fix the fallout that occurs
when building with --enable-developer. Note that we get different
warnings on different machines and so this will be a work in
progress. So far, we have built on NetBSD/amd64 5.99.64 (which
uses gcc 4.5.3) and Ubuntu 10.04.3 LTS (which uses gcc 4.4.3).
Notably, we fixed
1. a lot of missing structure initialisers,
2. unchecked return values for functions that glibc
marks as __attribute__((warn-unused-result)),
3. made minor modifications to slc and asn1_compile
which can generate code which generates warnings,
and
4. a few stragglers here and there.
We turned off the extended warnings for many programs in appl/ as
they are nearing the end of their useful lifetime, e.g. rsh, rcp,
popper, ftp and telnet.
Interestingly, glibc's strncmp() macro needed to be worked around
whereas the function calls did not.
We have not yet tried this on 32 bit platforms, so there will be
a few more warnings when we do.
