ping
On Oct 10 22:02:20, [email protected] wrote:
> On Oct 10 15:22:01, [email protected] 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
>
