This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Plug a couple of memory leaks


> Roland McGrath, le Tue 20 Jul 2010 19:27:36 -0700, a écrit :
> > > 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.
> 
> Mmm, but they don't handle KERN_NO_SPACE (ENOMEM) and
> KERN_INVALID_ARGUMENT (EINVAL).

That's true.  Those are only handled by __hurd_fail for when you've made a
mach_* call.  Actual Hurd RPCs should always return the canonical Hurdish
error codes.  It's conceivable that the mach_msg call making an RPC could
fail with KERN_NO_SPACE for receiving out of line data or something.  I'm
not sure whether that happens or not.  If it does, we should translate
KERN_NO_SPACE there too.  (And obviously it wouldn't hurt to cover it anyway.)

But, off hand, I don't think it should be possible (kosherly) for those
microkernel errors to be the result of some Hurd RPC made on a socket or fd.


Thanks,
Roland


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]