From owner-freebsd-bugs@FreeBSD.ORG Fri Feb 4 20:16:46 2005 Return-Path: Delivered-To: freebsd-bugs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1408D16A4CE for ; Fri, 4 Feb 2005 20:16:46 +0000 (GMT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id E29BA43D1D for ; Fri, 4 Feb 2005 20:16:44 +0000 (GMT) (envelope-from m@MHoerich.de) Received: (qmail invoked by alias); 04 Feb 2005 20:16:42 -0000 Received: from pD9E58B80.dip.t-dialin.net (EHLO localhost) (217.229.139.128) by mail.gmx.net (mp008) with SMTP; 04 Feb 2005 21:16:42 +0100 X-Authenticated: #5114400 Date: Fri, 4 Feb 2005 21:16:22 +0100 From: Mario Hoerich To: Fergus Cameron Message-ID: <20050204201622.GA29998@Pandora.MHoerich.de> References: <200502040930.j149UQDc043307@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200502040930.j149UQDc043307@freefall.freebsd.org> User-Agent: Mutt/1.4.2.1i Organization: University of Paderborn X-Y-GMX-Trusted: 0 cc: freebsd-bugs@FreeBSD.org Subject: Re: bin/77031: [patch] comm(1) unable to handle lines greater than LINE_MAX (2048) X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2005 20:16:46 -0000 # Fergus Cameron: > http://people.freebsd.org/~keramida/fergus/comm.c-diff Ok, I must admit your patch _is_ far easier on the malloc(3) side than the one I posted to -current a while back. I've briefly considered to rewrite it, but since your's was the only feedback I got (thanks btw) there's probably not much interest in my solution anyway. Oh well. Now to your patch. What I've noticed while doing a preliminary review (bit short on time right now) was: file1 = file( argv[0] ) ; file2 = file( argv[1] ) ; if( file1 == file2 ) errx( EXIT_FAILURE, "cannot match file against self" ) ; You sure this is guaranteed to trigger? I'm not standard- savvy enough to know for sure, but it seems like a potential problem. Anyone with a definitive answer? In addition to that, how does fgetws_a() cope with files, which have no '\n' in their last line? (They should of course, but every once in a while some file has not.) I might be wrong here, but it seems the do { ... } while (line_p) doesn't terminate properly in that case. Just scanning through though, might have missed something. Regards, Mario