Re: bug#13530: head: memory exhausted when printing all from stdin but last P/E bytes

[Jim Meyering]

Pádraig Brady wrote:

> unarchive 13530
> stop

Thanks.

...
>> @@ -358,6 +356,14 @@ elide_tail_bytes_pipe (const char *filename, int fd, 
>> uintmax_t n_elide_0)
>>
>>            if (buffered_enough)
>>              {
>> +              if (n_elide_0 != n_elide)
>> +                {
>> +                  error (0, 0, _("memory exhausted while reading %s"),
>> +                         quote (filename));
>> +                  ok = false;
>> +                  goto free_mem;
>> +                }
>> +
...
> Oh right it's coming back to me a bit now.
> So by removing these upfront checks where possible,
> it only makes sense of the program could under different
> free mem available, fulfil the operation up to the specified limit.
> In this case though, the program could never fulfil the request,
> so it's better to fail early as is the case in the code currently?

Well, it *can* fulfill the request whenever the request is degenerate,
i.e., when the size of the input is smaller than N and also small enough
to be read into memory.

Technically, we could handle this case the same way we handle it
in tac.c: read data from nonseekable FD and write it to a temporary file.
I'm not sure it's worth the effort here, though.

...
>> -(ulimit -v 20000; head --bytes=-E < /dev/null) || fail=1
>> +(ulimit -v 20000; head --bytes=-$OFF_T_MAX < /dev/null) || fail=1

I'm inclined to make the above (nonseekable input) cases succeed,
for consistency with the seekable-input case like this:

    : > empty
    head --bytes=-E empty

I confess that I did not like the way my manual test ended up
using so much memory... but it couldn't know if it was going
to be able to succeed without actually reading/allocating all
of that space.

If we give up immediately, we fail unnecessarily in cases like
the above where the input is smaller than N.

What do you think?