Re: [PATCH] Plug a couple of memory leaks

[Roland McGrath <roland at redhat dot com>]

Your mailer or editor line-wrapped part of your patch, so I had to fiddle
it to make it apply.  Please be more careful about that sort of thing.

> This patch fixes a couple of leaks in sendmsg(). I was not sure whether
> to add an out: label at the end of the function (where it deallocates
> 'data') and goto there in both cases, but it calls __hurd_sockfail()
> there which I'm not sure is correct when returning from
> e.g. __file_name_lookup (which is not a socket syscall, although we're in
> sendmsg() which is).

No, your patch is correct as it is.  __hurd_sockfail should only be called
for the results of the socket_* RPC that got the same FLAGS argument.

> Also, if calling __hurd_sockfail() after __ifsock_getsockaddr() is fine, we
> would need to call __hurd_fail() before, since __hurd_sockfail() doesn't call
> it. Is there a reason why it doesn't?

No, you've misunderstood.  __hurd_sockfail calls _hurd_fd_error, which is
what __hurd_dfail calls.  These do appropriate magic for the same special
case RPC errors that __hurd_fail handles.  The right magic when the RPC was
to an fd is different from the generic magic.

> Finally, I'm curious at why the prototype is __libc_sendmsg and not just
> __sendmsg. If there is a file explaining all this magic, just point me to
> it and I'll be happy to read it.

Sorry, it's lost in the mists of time.  The short answer is because that's
what we've always done for this call, and Linux configurations of glibc
also give that name to sendmsg.  (But note that it is not in the dynamic
symbol table, so its presence only affects static linking.)  Really the
stub definition in socket/sendmsg.c ought to define the same name too, so
it serves as the model for what symbols and types the function needs to use
in any configuration.


Thanks,
Roland