Jim Meyering <[EMAIL PROTECTED]> wrote: > Arnaldo Mandel <[EMAIL PROTECTED]> wrote: >> Dear maintainers, >> >> There is a bug in the implementation of the -L parameter in wc. >> It is triggered by >> >> http://www.ime.usp.br/~am/122/eps/gapqm2.gz >> >> Check this out: >> >> $ zcat gapqm2.gz |wc -l -c -L >> 1 6297954 6353180 >> >> That is, the single line is longer than the whole file. >> >> This was pointed out by >> >> William A. M. Gnann <[EMAIL PROTECTED]> > > Thanks for reporting it and for giving credit. > FYI, here's a smaller reproducer: > > $ printf '\t'|wc -L > 8
This behavior is not specified, and is currently untested. (it's a GNU invention, from Bruno Haible in textutils-1.22d, which was back in 1997) http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=ab5ff1597f5d734b711fbd95389cefcc8203d51c I.e., the following change to make --max-line-length (-L) never count a TAB as more than one byte does not induce any test failure. I'm tempted to make the change, but it seems too drastic, after 11 years. Do any of you rely on the current TAB-counting behavior of GNU wc? Bruno, what do you think? diff --git a/src/wc.c b/src/wc.c index 0bb1929..d44cf96 100644 --- a/src/wc.c +++ b/src/wc.c @@ -363,7 +363,7 @@ wc (int fd, char const *file_x, struct fstatus *fstatus) linepos = 0; goto mb_word_separator; case '\t': - linepos += 8 - (linepos % 8); + linepos++; goto mb_word_separator; case ' ': linepos++; @@ -437,7 +437,7 @@ wc (int fd, char const *file_x, struct fstatus *fstatus) linepos = 0; goto word_separator; case '\t': - linepos += 8 - (linepos % 8); + linepos++; goto word_separator; case ' ': linepos++; _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
