Re: Weirdness in comm(1)

["D'Arcy J.M. Cain" <darcy%NetBSD.org@localhost>]

On Sat, 28 Nov 2009 18:30:14 +0100
Joerg Sonnenberger <joerg%britannica.bec.de@localhost> wrote:
> > 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.

Of course not.  That's the original problem with comm(1).  Programs
like sort(1) treat newlines as the line separator but comm(1) treats it
as part of the line.  That's the crux of the disconnect.

> (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.

I thought that getline(3) was too new to have idioms yet.  Wasn't it
just added a few months ago?  It's not even in an official release.

> 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.

I suppose.  It means that we still need a getnextln function in comm.c
to handle that.  We can't just call getline directly.

-- 
D'Arcy J.M. Cain <darcy%NetBSD.org@localhost>
http://www.NetBSD.org/