Re: [PATCH 2/3] Add the code for starting up the mountee

[Sergiu Ivanov]

Hello,

On Fri, Jul 10, 2009 at 07:10:07PM +0200, Carl Fredrik Hammar wrote:
> On Fri, Jul 10, 2009 at 04:17:23AM +0200, olafBuddenhagen@gmx.net wrote:
> > > > > +  /*Opens the port on which to set the new translator */
> > > > > +  error_t
> > > > > +    open_port
> > > > > +    (int flags, mach_port_t * underlying,
> > > > > +     mach_msg_type_name_t * underlying_type, task_t task, void 
> > > > > *cookie)
> > > > 
> > > > AFAIK open_port should not be indented, and the parameter list should
> > > > start on the same line.
> > > 
> > > I read in the GCS that emacs should be considered as an expert in GCS
> > > indentation, and it indents things like this.  Which authority should
> > > I comply with?
> > 
> > In general, the existing code is the authority. From what I've seen so
> > far, this is handled very consistently in all existing Hurd code, and
> > unionfs in fact has many examples.
> 
> Also most code I've seen in the hurd has the return type on the same line.
> The reasoning to have the return type on a seperate line is to get the
> function name in column 0 so it can be easily grepped.  But that
> obviously can't be applied to nested functions.

Yeah, right.  Thanks for pointing this out!  I didn't really remember
this detail until I actually came over other nested functions in
unionfs.  I guess the fact that emacs did this weird indentation is
due to the fact that I didn't position the name of the function on the
same line as its return value.

Regards,
scolobb