From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from scc-mailout.scc.kit.edu (scc-mailout.scc.kit.edu [129.13.185.202]) by krisdoz.my.domain (8.14.3/8.14.3) with ESMTP id p674DP5D002421 for ; Thu, 7 Jul 2011 00:13:28 -0400 (EDT) Received: from hekate.usta.de (asta-nat.asta.uni-karlsruhe.de [172.22.63.82]) by scc-mailout-02.scc.kit.edu with esmtp (Exim 4.72 #1) id 1Qefxs-0001Zy-5q; Thu, 07 Jul 2011 06:13:24 +0200 Received: from donnerwolke.usta.de ([172.24.96.3]) by hekate.usta.de with esmtp (Exim 4.72) (envelope-from ) id 1Qefxs-000707-7i for tech@mdocml.bsd.lv; Thu, 07 Jul 2011 06:13:24 +0200 Received: from iris.usta.de ([172.24.96.5] helo=usta.de) by donnerwolke.usta.de with esmtp (Exim 4.69) (envelope-from ) id 1Qefxs-00017U-6R for tech@mdocml.bsd.lv; Thu, 07 Jul 2011 06:13:24 +0200 Received: from schwarze by usta.de with local (Exim 4.72) (envelope-from ) id 1Qefxs-000487-5Z for tech@mdocml.bsd.lv; Thu, 07 Jul 2011 06:13:24 +0200 Date: Thu, 7 Jul 2011 06:13:24 +0200 From: Ingo Schwarze To: tech@mdocml.bsd.lv Subject: Re: sync results Message-ID: <20110707041324.GD15627@iris.usta.de> References: <20110704224519.GC28684@iris.usta.de> <4E1306FA.3070801@bsd.lv> <4E131A74.3050900@bsd.lv> X-Mailinglist: mdocml-tech Reply-To: tech@mdocml.bsd.lv MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E131A74.3050900@bsd.lv> User-Agent: Mutt/1.5.21 (2010-09-15) Hi Kristaps, Kristaps Dzonsons wrote on Tue, Jul 05, 2011 at 04:06:44PM +0200: > Kristaps wrote: >> Ingo wrote: >>> nsd-xfer(8) contains this code: >>> >>> .SH "OPTIONS" >>> .LP >>> .TP >>> .B \-4 >>> Only send to IPv4 addresses. >>> >>> In groff and old mandoc, there is no blank line after OPTIONS, >>> now there is one. >> Ouch, this is indeed a bug: the syntax tree appears to be messed up by >> the removal of the `LP'. I'll look into it... > Please check if the enclosed patch fixes this problem Yes, it does. > without fallout. I don't see any new regressions. > Basically, the "next node append type" for -man was > automatically being set to NEXT, clobbering the value set during > node deletion in the post-validator. This was causing the `LP' to > be removed and the next node, the `TP', being assigned under the > block of `SH'. Ew. I eye-balled it over a selection of -man and > ran it over my regular tests for failure. This is quite an old bug, > it turns out. Somehow, it must have been uncovered by recent changes elsewhere, or it wouldn't have shown up as an regression. Anyway, investigating the details why it remained hidden looks like a waste of time. So, ok schwarze@ and committed to OpenBSD. Thanks, Ingo > Index: man_macro.c > =================================================================== > RCS file: /usr/vhosts/mdocml.bsd.lv/cvs/mdocml/man_macro.c,v > retrieving revision 1.63 > diff -u -r1.63 man_macro.c > --- man_macro.c 18 Jun 2011 17:36:52 -0000 1.63 > +++ man_macro.c 5 Jul 2011 14:01:28 -0000 > @@ -120,6 +120,9 @@ > > assert(to); > > + assert(MAN_ROOT != m->last->type); > + m->next = MAN_NEXT_SIBLING; > + > /* LINTED */ > while (m->last != to) { > /* > @@ -140,9 +143,6 @@ > if ( ! man_valid_post(m)) > return(0); > > - m->next = MAN_ROOT == m->last->type ? > - MAN_NEXT_CHILD : MAN_NEXT_SIBLING; > - > return(1); > } > > @@ -428,6 +428,9 @@ > assert( ! (MAN_SCOPED & man_macros[tok].flags)); > m->flags |= MAN_ILINE; > } > + > + assert(MAN_ROOT != m->last->type); > + m->next = MAN_NEXT_SIBLING; > > /* > * Rewind our element scope. Note that when TH is pruned, we'll > @@ -452,9 +455,6 @@ > > if (m->last->type != MAN_ROOT && ! man_valid_post(m)) > return(0); > - > - m->next = MAN_ROOT == m->last->type ? > - MAN_NEXT_CHILD : MAN_NEXT_SIBLING; > > return(1); > } -- To unsubscribe send an email to tech+unsubscribe@mdocml.bsd.lv