From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp-1.sys.kth.se (smtp-1.sys.kth.se [130.237.32.175]) by krisdoz.my.domain (8.14.3/8.14.3) with ESMTP id p0ONGQSP012278 for ; Mon, 24 Jan 2011 18:16:26 -0500 (EST) Received: from mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) by smtp-1.sys.kth.se (Postfix) with ESMTP id EEDE51558AA; Tue, 25 Jan 2011 00:16:20 +0100 (CET) X-Virus-Scanned: by amavisd-new at kth.se Received: from smtp-1.sys.kth.se ([130.237.32.175]) by mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) (amavisd-new, port 10024) with LMTP id Bp4AvUdL+hep; Tue, 25 Jan 2011 00:16:19 +0100 (CET) X-KTH-Auth: kristaps [85.8.61.158] X-KTH-mail-from: kristaps@bsd.lv Received: from h85-8-61-158.dynamic.se.alltele.net (h85-8-61-158.dynamic.se.alltele.net [85.8.61.158]) by smtp-1.sys.kth.se (Postfix) with ESMTP id A03EC1557D7; Tue, 25 Jan 2011 00:16:19 +0100 (CET) Message-ID: <4D3E0843.1010608@bsd.lv> Date: Tue, 25 Jan 2011 00:16:19 +0100 From: Kristaps Dzonsons User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 X-Mailinglist: mdocml-tech Reply-To: tech@mdocml.bsd.lv MIME-Version: 1.0 To: tech@mdocml.bsd.lv CC: Ingo Schwarze Subject: Re: line termination in manuals References: <20110122195656.GE12520@iris.usta.de> <20110122200516.GA26592@britannica.bec.de> <20110122212814.GH12520@iris.usta.de> <20110122213510.GA29547@britannica.bec.de> <20110122221836.GJ12520@iris.usta.de> <20110122222938.GA30488@britannica.bec.de> <20110122225933.GL12520@iris.usta.de> In-Reply-To: <20110122225933.GL12520@iris.usta.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit >> Has somebody checked whether groff accepts these in the same way? > > It does. > > > Joerg Sonnenberger wrote on Sat, Jan 22, 2011 at 11:29:38PM +0100: >> On Sat, Jan 22, 2011 at 11:18:36PM +0100, Ingo Schwarze wrote: > >>> When the last character in blk.buf is '\r' (without a newline >>> at the end of the file), my first attempt would have overrun >>> the buffer by one byte. > >> Right. What about the same condition for the first if? > > Has anybody mentioned that handling of null-terminated strings > is less error-prone than of buffers with a length, because there > is the null at the end and you don't that easily overrun? > > Joerg, you are right, and not only that, the bounds check was off > by one as well. Checking i+1< sz and then accessing buf[i+2] > is not smart. > > Maybe i should write poems instead, or something. .Dd $Mdocdate$ .Dt FOO 1 .Os .Sh NAME .Nm foo .Nd a poem by pretend\-Ingo .Sh SYNOPSIS .Nm Roses .Ar e red, violets .Ar e blue... Incidentally, whenever you get the \r\n logic ironed out, check it in. I've been wanting to have DOS file support for a while... (Should we specify that the -Tascii output is always UNIX newline terminated?) Thanks, Kristaps -- To unsubscribe send an email to tech+unsubscribe@mdocml.bsd.lv