From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp1.rz.uni-karlsruhe.de (Debian-exim@smtp1.rz.uni-karlsruhe.de [129.13.185.217]) by krisdoz.my.domain (8.14.3/8.14.3) with ESMTP id oB2Kscvf007377 for ; Thu, 2 Dec 2010 15:54:39 -0500 (EST) Received: from hekate.usta.de (asta-nat.asta.uni-karlsruhe.de [172.22.63.82]) by smtp1.rz.uni-karlsruhe.de with esmtp (Exim 4.63 #1) id 1POGAn-0001Jm-Cg; Thu, 02 Dec 2010 21:54:37 +0100 Received: from donnerwolke.usta.de ([172.24.96.3]) by hekate.usta.de with esmtp (Exim 4.72) (envelope-from ) id 1POGAn-0005zo-BS for tech@mdocml.bsd.lv; Thu, 02 Dec 2010 21:54:37 +0100 Received: from iris.usta.de ([172.24.96.5] helo=usta.de) by donnerwolke.usta.de with esmtp (Exim 4.69) (envelope-from ) id 1POGAn-0004ov-AR for tech@mdocml.bsd.lv; Thu, 02 Dec 2010 21:54:37 +0100 Received: from schwarze by usta.de with local (Exim 4.72) (envelope-from ) id 1POGAn-0004AY-9h for tech@mdocml.bsd.lv; Thu, 02 Dec 2010 21:54:37 +0100 Date: Thu, 2 Dec 2010 21:54:37 +0100 From: Ingo Schwarze To: tech@mdocml.bsd.lv Subject: Re: roff.c question Message-ID: <20101202205437.GC12188@iris.usta.de> References: <4CF678F0.6020304@bsd.lv> <20101201212834.GA22990@iris.usta.de> <4CF77A2B.6020702@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: <4CF77A2B.6020702@bsd.lv> User-Agent: Mutt/1.5.21 (2010-09-15) Hi Kristaps, >> I'll probably split exit_status into two variables: >> First, file_status will be initialized to MANDOCERR_OK for each >> file, and that's the one mmsg will write to. >> Then, at the end of each file, the contents must be moved to >> exit_status, in case it's more severe than what is already there. That was so easy that i have just put it in. > Another question---I'm about to check in roff.c as fully in sync > after running some more tests---I notice that `de1' has been removed > from the switch statement at roff.c:549. I understand this is > because `de1' is renamed at roff.c:636. Exactly. > If this is the case, can you document this process a bit more? I guess i should do that when touching roff.c the next time, which might happen soon... > There's also an infinite loop somewhere in these new roff.c changes > that's causing the NetBSD manuals to blow up... ... given that i'm now starting to look into that one. Yours, Ingo -- To unsubscribe send an email to tech+unsubscribe@mdocml.bsd.lv