Re: burned by Makefile.in.in's $(DOMAIN).pot-update rule

[Paolo Bonzini]

> These commands inspect only the files in the package to which that Makefile
> belongs. I think it is reasonable to assume that a user doesn't have weird
> files (terabyte-sized files, sockets, named pipes, etc.) in such a place.

Even a gigabyte-sized file is not weird for people who work in
virtualization, and it can have a _lot_ of consecutive non-LF bytes.
Maybe it won't send the machine into swap, but it will take a long
time to mbrtowc and grep that file. If you rely on git mirroring to
backup your development directories, it is not weird to be in this
situation.

> You (or some auxiliary script) might have issued similar 'grep' commands as
> well.

Not a justification in my opinion.

> I think it is reasonable for 'grep' to allocate as much memory as the
> longest line in the file has.

Of course. And unless your grep is broken in that it doesn't treat NUL
bytes correctly, it cannot really special case holes in any way.

> I think 'core' files of a.out format had holes under Linux, but this was fixed
> with the adoption of ELF, in 1995: AFAICS, ELF core files are not sparse.

Why is this relevant?

Paolo