Hi, On Tue, Jun 01, 2010 at 11:32:32AM +0200, Carl Fredrik Hammar wrote: > On Tue, Jun 01, 2010 at 03:50:26AM +0200, olafbuddenha...@gmx.net wrote:
> > Hm... Does glibc have a strict 80-chars-or-die policy? I always > > considered this ridiculous... > > I don't think it's strict as there are examples of such code in glibc. > I might be projecting my own aversion to long lines here, so tell me if > you think I'm being too strict. I think you are being too strict :-) > > > 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? > > Yes, see exec/exec.c:1510 in Hurd and libidn/stringprep.c:192 in glibc. OK. > I actually think this style should be used more for huge function calls > like this. It makes the indentation less "jumpy". Indeed... Never liked the "everything at end of line" style -- I don't see how this is supposed to help readability. > > BTW, how about breaking after the '='? I think I saw this in other code > > -- though I don't know in what projects... > > That is also an option though I think the above is better in this case > since "error_t err =" is shorter than "__file_exec_file_name" so you > don't gain as much room. Interestingly, indent does both breakings in > this case but that seems unnecessary. Well, in general, "indent" should be considered the reference -- unless it does something obviously stupid... -antrik-
