Re: Gnumach cleanup 11

How about this one? Not too sure about the syntax of the changelog. Thanks! Barry deFreese 2008-07-23 Barry deFreese <[EMAIL PROTECTED]> * i386/i386/locore.h (copyinmsg, copyoutmsg): Cast parameters as void* rather than vm_offset_t. * i386/i386at/com.c (comportdeath

Re: Gnumach cleanup 11

Barry deFreese, le Tue 22 Jul 2008 13:33:07 -0400, a écrit : > I'm a little curious if using (void *)port cast is correct in the calls > to tty_portdeath()? Rather cast into the target type instaed, ipc_port_t. > I also could use some guidance on these warnings (they all come from > basically t

Re: glibc's hurd/fd-read.c

> Shouldn't we nevertheless `vm_deallocate' the memory region? Yes, thanks.

Gnumach cleanup 11

Hi folks, Here is another patch that cleans up the "makes foo from bar without a cast" warnings. I'm a little curious if using (void *)port cast is correct in the calls to tty_portdeath()? I also could use some guidance on these warnings (they all come from basically the same call): ../k

syslog (was: hangs)

Hello! On Tue, Jul 22, 2008 at 02:33:34PM +0100, Samuel Thibault wrote: > It looks like the hangs we're encountering on flubber/gnubber and which > I'm having on the buildd are due to syslog() blocking somewhere. Interesting... While being at syslog, I can again point to this issue,

hangs

It looks like the hangs we're encountering on flubber/gnubber and which I'm having on the buildd are due to syslog() blocking somewhere. Samuel

Re: glibc's hurd/fd-read.c

Hello! On Mon, Jul 21, 2008 at 12:50:50PM -0700, Roland McGrath wrote: > It's bogus, i.e. a violation of Hurd protocols, for an io server to send > back more data than requested. But it's possible with a buggy or malicious > server. So it is appropriate paranoia on the client side to check for t