Hi, I notice uniq -f 'insane_large_number' will make process to be busy long time without good reason. Attached patch should fix this symptom.
I found the bug after friend of mine asked why uniq does not allow specifying field separator, similar way sort -t. I could not answer anything rational, so I look the code and tested how it works. That inspired me to send bug fix, which is obvious thing to do. But how about that -t, do you think this would be worth while addition to uniq? -- Sami Kerola http://www.iki.fi/kerolasa/
From 4652493c90940e5460ccfeb8ed3e231e06ee46dc Mon Sep 17 00:00:00 2001 From: Sami Kerola <[email protected]> Date: Mon, 17 Jan 2011 00:27:06 +0100 Subject: [PATCH] uniq: don't continue field processing after end of line * NEWS (Bug fixes): Mention it. * src/uniq.c (find_field): Stop processing loop when end of line is reached. Before this fix 'uniq -f 10000000000 /etc/passwd' ran quite long time. --- NEWS | 3 +++ src/uniq.c | 2 +- 2 files changed, 4 insertions(+), 1 deletions(-) diff --git a/NEWS b/NEWS index 9ccad63..71018dd 100644 --- a/NEWS +++ b/NEWS @@ -13,6 +13,9 @@ GNU coreutils NEWS -*- outline -*- rm -f no longer fails for EINVAL or EILSEQ on file systems that reject file names invalid for that file system. + uniq -f NUM will no longer try to process lines after end of + line is reach. + * Noteworthy changes in release 8.9 (2011-01-04) [stable] diff --git a/src/uniq.c b/src/uniq.c index 7bdbc4f..6fa6cc9 100644 --- a/src/uniq.c +++ b/src/uniq.c @@ -214,7 +214,7 @@ find_field (struct linebuffer const *line) size_t size = line->length - 1; size_t i = 0; - for (count = 0; count < skip_fields; count++) + for (count = 0; count < skip_fields && count < line->length; count++) { while (i < size && isblank (to_uchar (lp[i]))) i++; -- 1.7.3.5
