Re: Weirdness in comm(1)

[Joerg Sonnenberger <joerg%britannica.bec.de@localhost>]

On Sat, Nov 28, 2009 at 12:24:06PM -0500, D'Arcy J.M. Cain wrote:
> On Fri, 27 Nov 2009 20:49:31 +0100
> Joerg Sonnenberger <joerg%britannica.bec.de@localhost> wrote:
> > On Fri, Nov 27, 2009 at 10:30:25AM -0500, D'Arcy J.M. Cain wrote:
> > > Here's a little script that shows the issue.  The attached patch fixes
> > > it.  Id does make it a bit busier but comm(1) would work right.  Unless
> > > someone has a reason not to I will commit this later today.
> > 
> > Please use getline instead and just make line1 and line2 dynamically
> > allocated. There is no point in having a line limit here and getline is
> > reasonable efficient.
> 
> I just looked at the getline function and it seems that it still
> includes the newline.  That's the basic problem with fgets for comm and
> is the reason I wrote my getnextln function.

(a) I don't think in this context a line without \n and a line with \n
are equival.

(b) Removing the trailing \n doesn't allow correct handling of files
that don't end in \n for many typical applications. Most importantly, it
means the common while (getline()) fputs() idiom would create a
different result.

There are different issues with fgets -- leaving the delimiter is
certainly not the biggest. Note that getline returns the number of
characters read, so removing the delimiter if needed involves just a
simple check in the array.

Joerg