Using bidirectional authentication in pkgng

Dag-Erling Smørgrav des at
Thu Jan 24 15:23:56 UTC 2013

Michael Gmelin <freebsd at> writes:
> Dag-Erling Smørgrav <des at> writes:
> >  - Several lines are too long, and almost all your continuation lines
> >    are misindented.
> Hm, I used an emacs mode that was supposed to indent according to
> style(9) - so maybe that wasn't the right tool.  Do you have a link to
> an emacs mode that works like expected? (I clearly won't do these
> indentations manually, they're so counter-intuitive to me that I would
> mess them up badly - it's hard to work against your organization's
> usual coding style and switching back and forth).  Any recommended
> combination of lint/indent/whatever I could use to validate the code
> automatically?

(defun des-knf ()
  (c-set-style "bsd")

  ;; Basic indent is 8 spaces
  (setq c-basic-offset 8)
  (setq tab-width 8)

  ;; Continuation lines are indented 4 spaces
  (c-set-offset 'arglist-intro 4)
  (c-set-offset 'arglist-cont 4)
  (c-set-offset 'arglist-cont-nonempty 4)
  (c-set-offset 'statement-cont 4)
  (c-set-offset 'cpp-macro-cont 8)

  ;; Labels are flush to the left
  (c-set-offset 'label [0])

  ;; Fill column
  (setq fill-column 74))

(add-hook 'c-mode-common-hook 'des-knf)

but Emacs will still misindent continuation lines in some cases,
e.g. when a line break occurs within nested parentheses; AFAICT from the
documentation, there is no way to tune that.

> I just checked, all lines I added are <80 characters. Style(9) itself
> doesn't specify any line length limitations, so I figured staying
> below 80 is already quite conservative (or are you going really old
> school and limit yourself to 72?).  Since I found quite a number of
> lines that are longer than that I figured it would be ok.

I wrap comments at 74, and *try* to keep code closer to 74 than 80.

Some of the code in http.c is so deeply nested that it is almost
impossible to stay within 80 characters.  This is a clear sign that the
code needs to be rewritten.

BTW, you'd have an easier time avoiding long lines if you used shorter
function and variable names and assigned commonly used expressions to
temporary variables, e.g. (matcheslen - (firstmatchdot - matches) in

> >  - You declare variables inside blocks, and declarations in general
> > are not properly sorted.
> I wasn't aware that this is not allowed (it's such an incredibly
> useful feature to me).

s/not allowed/strongly discouraged/

> Could you point me to the section in style(9) that specifies this
> (couldn't find it)?

     Parts of a for loop may be left empty.  Do not put declarations inside
     blocks unless the routine is unusually complicated.

> > There are issues with the man page as well - you didn't bump the
> > date, sentences don't begin on new lines, and some lines are too
> > long - but you get a million bonus points for updating it at all.
> Do you have a good pointer to style guides for man pages/nroff? Didn't
> bump the date since I figured it won't be accepted unchanged anyway.

The closest we have is mdoc(7).  I'm not sure where / whether the
requirement to start sentences on a new line is documented, but this is
actually a feature of *roff rather than a style issue; it has to be able
to tell the difference between the period that follows an abbreviation
and the period at the end of a sentence.  For the same reason, Emacs
will never insert a line break after a period followed by a single
space when wrapping text.

Dag-Erling Smørgrav - des at

More information about the freebsd-ports mailing list