From owner-freebsd-hackers@FreeBSD.ORG Sun May 17 11:09:04 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BA0D6A89 for ; Sun, 17 May 2015 11:09:04 +0000 (UTC) Received: from elektropost.org (elektropost.org [217.115.13.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0D89A1225 for ; Sun, 17 May 2015 11:09:02 +0000 (UTC) Received: (qmail 6377 invoked from network); 17 May 2015 11:02:18 -0000 Received: from elektropost.org (HELO elektropost.org) (erdgeist@erdgeist.org) by elektropost.org with ESMTPS (DHE-RSA-AES128-SHA encrypted); 17 May 2015 11:02:18 -0000 Message-ID: <5558752E.8030404@erdgeist.org> Date: Sun, 17 May 2015 13:02:06 +0200 From: Dirk Engling User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: lam silently spills overly long lines Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 May 2015 11:09:04 -0000 Dear all, when working on a set of files quite large files I noticed that lam(1) would suddenly start combining lines that clearly don't belong together. I tracked it down to a single overly long line (with overly meaning > BUFSIZ from stdio.h) in one of the files and noticed that in https://svnweb.freebsd.org/base/head/usr.bin/lam/lam.c?revision=227240&view=markup#l201 the function gatherline would not consume all chars up to the eol marker for that file, leaving the reminder of that particular input line fragment for the next output line, in turn screwing up the output. I find that behaviour surprising and would expect a) lam not to choke on lines over an arbitrary size limit or b) try to get itself in a consistent state in this easily to understand situation and/or c) exit or at least issue a warning while doing something unexpected. I finally switched to using the paste(1) tool where this problem does not occur but still found the issue annoying enough to send this email. I also offer to write the patch. erdgeist