bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Use the new __hurd_exec_file_name RPC


From: olafBuddenhagen
Subject: Re: [PATCH] Use the new __hurd_exec_file_name RPC
Date: Tue, 1 Jun 2010 03:50:26 +0200
User-agent: Mutt/1.5.19 (2009-01-05)

Hi,

On Mon, May 31, 2010 at 06:16:06PM +0200, Carl Fredrik Hammar wrote:
> On Sat, May 22, 2010 at 06:26:29PM +0200, Emilio Pozuelo Monfort wrote:

> > +      err = __file_exec_file_name (file, task, flags,
> > +                              filename ? filename : "",
> > +                              args, argslen, env, envlen,
> > +                              dtable, MACH_MSG_TYPE_COPY_SEND, dtablesize,
> > +                              ports, MACH_MSG_TYPE_COPY_SEND, _hurd_nports,
> 
> Break this line.

Hm... Does glibc have a strict 80-chars-or-die policy? I always
considered this ridiculous...

> > +   error_t err = __file_exec_file_name (file, task,
> > +                                        (__sigismember (&_hurdsig_traced, 
> > SIGKILL)
> > +                                         ? EXEC_SIGTRAP : 0),
> > +                                        filename,
> > +                                        args, argslen, env, envlen,
> > +                                        dtable, MACH_MSG_TYPE_COPY_SEND, 
> > dtablesize,
> > +                                        ports, MACH_MSG_TYPE_COPY_SEND, 
> > _hurd_nports,
> > +                                        ints, INIT_INT_MAX,
> > +                                        NULL, 0, NULL, 0);
> 
> A bunch of lines should be broken here, but the first one is particularly
> tricky.  Do something like this instead:
> 
>       error_t err = __file_exec_file_name
>         (file, task,
>          __sigismember (&_hurdsig_traced, SIGKILL) ? EXEC_SIGTRAP : 0,
>          filename,
>          args, argslen, env, envlen,
>          dtable, MACH_MSG_TYPE_COPY_SEND, dtablesize,
>          ports, MACH_MSG_TYPE_COPY_SEND, _hurd_nports,
>          ints, INIT_INT_MAX,
>          NULL, 0, NULL, 0);

Not sure it's a good idea to be inconsistent here. I there precedent for
this?

BTW, how about breaking after the '='? I think I saw this in other code
-- though I don't know in what projects...

-antrik-



reply via email to

[Prev in Thread] Current Thread [Next in Thread]