On Oct 10 15:22:01, t...@tedunangst.com wrote:
> Jan Stary wrote:
> > Why do we need to trim the newlines in unexpand(1)?
> > The result seems to be the same without it.
> >
> > Jan
> >
> >
> > Index: unexpand.c
> > ===================================================================
> > RCS file: /cvs/src/usr.bin/unexpand/unexpand.c,v
> > retrieving revision 1.12
> > diff -u -p -r1.12 unexpand.c
> > --- unexpand.c 11 Nov 2015 02:52:46 -0000 1.12
> > +++ unexpand.c 10 Oct 2016 17:58:40 -0000
> > @@ -72,10 +72,6 @@ main(int argc, char *argv[])
> > argc--, argv++;
> > }
> > while (fgets(genbuf, BUFSIZ, stdin) != NULL) {
> > - for (cp = linebuf; *cp; cp++)
> > - continue;
> > - if (cp > linebuf)
> > - cp[-1] = 0;
>
> this really looks like a bug using the wrong variable. genbuf and linebuf are
> different arrays.
In the current code, these four lines are pointless,
because the linebuf gets overwritten anyway in the subsequent tabify().
Changing this to genbuf indeed trims the newlines from the _input_
(as was maybe intended), but then they are also missing
in the output, wrongly.
Removing those four lines seems to give the expected output,
as long as the input line length is < BUFSIZ (= 1024).
On a line consisting of 1026 spaces, ten spaces will be left
- but that's because the buffer does not see far enough.
Maybe that's why the (botched) erasing of the newline is there?
To catch the case when \n happens to be the BUFSIZE-th char,
thus catching one extra tab that would be missed otherwise?
Jan
