On 08/07/2012 07:08 PM, Hugh Dickins wrote: > wouldn't the developer's common case (object files amidst source > in the tree) usually be handled by that check on the first 32k? Yes, but grep should also handle the less-common case where the first 32K is text and there's a large hole later. The particular case I'm worried about is a denial-of-service attack, so it's irrelevant that this case is uncommon in typical files. > shouldn't grep instead just be > checking for over-long lines instead of running out of memory? GNU programs should not have arbitrary limits. An arbitrary limit, such as 100,000 bytes, that we put on line length, would cause grep to not work on some valid inputs. This is not to say that grep couldn't function better on files with lots of nulls -- it can, and that's on our list of things to do -- but SEEK_HOLE is a big and obvious win in this area. We also need SEEK_HOLE and SEEK_DATA for GNU 'tar', for the same reason (denial-of-service attacks, mostly). -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
