Re: Gnumach cleanup 10 attempt3

On Tue, 2008-07-22 at 03:37 +0100, Samuel Thibault wrote: > Barry deFreese, le Mon 21 Jul 2008 22:15:17 -0400, a écrit : > > (kdstop): Return 0 at end of function. > > Mmm, kdstop should probably just return void, like kdstart. You'll also > need to fix the t_stop and t_start members of struct

Re: Gnumach cleanup 10 attempt3

Barry deFreese, le Mon 21 Jul 2008 22:15:17 -0400, a écrit : > (kdstop): Return 0 at end of function. Mmm, kdstop should probably just return void, like kdstart. You'll also need to fix the t_stop and t_start members of struct tty accordingly. Else, it looks fine. Samuel

Re: pflocal's ports, references and S_socket_name()

I think that's right. sock_get_addr adds a ref, and you want leave with no refs added except the one implied by the live send rights.

Gnumach cleanup 10 attempt3

Here they are again. Thanks, Barry deFreese 2008-07-19 Barry deFreese <[EMAIL PROTECTED]> * chips/busses.h (struct bus_ctlr): *intr return void instead of int. * i386/i386/ipl.h (ivect[]): return void instead of int. * i386/i386at/pic_isa.h (ivect[]): Likewise.

pflocal's ports, references and S_socket_name()

Hello, We are having troubles with tcl, basically a=`tclsh` does not return, because the pipe says there is still a writer (although tclsh is dead). It looks like it is a reference which is not dropped in pflocal/socket.c:S_socket_name() (which tclsh calls on stdout): error_t S_socket_name (stru

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

The NREAD value is filled by the RPC stub from kernel-supplied message header bits, it's the actual amount of data in that part of the reply message. Unless there is a mig bug, it cannot be greater than the inline data limit passed in, i.e. nread <= *nbytes when data == buf, guaranteed at the IPC/

Re: Gnumach cleanup 10 second attempt

Barry deFreese, le Mon 21 Jul 2008 12:30:36 -0400, a écrit : > Samuel Thibault wrote: > >See the comment, they shouldn't be reached, so yes you can, but also add > >noreturn to the functions that are called just before, etc. ;) > > OK I'm getting closer. I added noreturn to exception and > except

Re: Gnumach cleanup 10 second attempt

Samuel Thibault wrote: Barry deFreese, le Mon 21 Jul 2008 11:33:57 -0400, a écrit : Samuel Thibault wrote: Indeed, but functions implicitely return at the end of it... And in that case, that's why I said to add noreturn to i386_exception and similar. exception() is one of those "simi

Re: Gnumach cleanup 10 second attempt

Barry deFreese, le Mon 21 Jul 2008 11:33:57 -0400, a écrit : > Samuel Thibault wrote: > > > >Indeed, but functions implicitely return at the end of it... > > > >And in that case, that's why I said to add noreturn to i386_exception > >and similar. exception() is one of those "similars". > > OK fai

Re: Gnumach cleanup 10 second attempt

Samuel Thibault wrote: Indeed, but functions implicitely return at the end of it... And in that case, that's why I said to add noreturn to i386_exception and similar. exception() is one of those "similars". Samuel Samuel, OK fair enough but exception() does do a few returns, you want me

Re: Gnumach cleanup 10 second attempt

Barry deFreese, le Mon 21 Jul 2008 11:01:31 -0400, a écrit : > Here is an updated patch. I hope I got it right this time. > > I added __attribute__ ((noreturn)) to i386_exception but I now get this > warning: > > ../i386/i386/trap.c: In function 'i386_exception': > ../i386/i386/trap.c:634: warni

Gnumach cleanup 10 second attempt

Here is an updated patch. I hope I got it right this time. I added __attribute__ ((noreturn)) to i386_exception but I now get this warning: ../i386/i386/trap.c: In function 'i386_exception': ../i386/i386/trap.c:634: warning: 'noreturn' function does return But I don't see a return anywhere!??

Re: Gnumach cleanup 10

Samuel Thibault wrote: Barry deFreese, le Sun 20 Jul 2008 23:46:24 -0400, a écrit : * i386/i386/ipl.h (ivect[]): return void instead of int. * i386/i386at/com.c (comintr, comstop): Return 0 at end of function. Err, that's not coherent: comintr is put in ivect... Ay

glibc's hurd/fd-read.c

Hello! In `[glibc]/hurd/fd-read.c', a ``memcpy (buf, data, nread)'' is being done. However, is it guaranteed, that `nread' is always less or equal to `*nbytes' (the size of `buf'), or should rather some ``MIN(nread, *nbytes)'' be used? The error of passing `nread' uninitialized was already fixe

Re: Gnumach cleanup 10

Barry deFreese, le Sun 20 Jul 2008 23:46:24 -0400, a écrit : > * i386/i386/ipl.h (ivect[]): return void instead of int. > * i386/i386at/com.c (comintr, comstop): Return 0 at end of function. Err, that's not coherent: comintr is put in ivect... > * i386/i386/trap.c (user_trap): R