bug#9800: Incomplete truncated file buffers from the /proc filesystem

["Arsen Arsenović via Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

[-- Attachment #1: Type: text/plain, Size: 1655 bytes --]

Hi,

I was just debugging this before I found the bug report.  The diagnosis
is right: st_size is wrong for proc files (and, I'd argue, for regular
files sometimes).  So, I agree with Paul.

Paul Eggert <eggert@cs.ucla.edu> writes:

> On 10/24/11 14:50, Richard Stallman wrote:
>> I think there was a reason for doing it this way.  Perhaps so as to
>> allocate the space before reading the file.
>
> Yes, that sounds right.  And in the typical case where the file is not
> growing, that allocates space efficiently.  If the file is growing, though,
> it's OK to allocate more space after discovering that the initial
> allocation was too small.

Right.  The best possible approach is, likely:

  fstat (fd, x, &st)
  bufsz = max (READ_BUF_SIZE, st.st_size)
  buf = malloc (bufsz)

  int ret = 0, readsz = 0;
  do
    {
      readsz += ret;
      if (readsz == bufsz && size isn't unreasonable)
        {
          /* value chosen arbitrarily.  */
          bufsz += min (16 * READ_BUF_SIZE, bufsz)
          buf = realloc (buf, bufsz)
        }
      errno = 0
      ret = read (fd, buf + readsz, bufsz - readsz)
    }
  while (ret > 0 || errno == EINTR);

... or such.  This approach is robust and general, and I suspect it'd
even work for named pipes.

st_size isn't a good enough indicator of size, and it can go out of date
before TOU, however, it's - no doubt - a useful hint in the 99% case.
Using st_size to figure out a base allocation size and extending
appropriately is a well known strategy, and it would be appropriate to
do so here.

Thanks in advance, have a great day.
-- 
Arsen Arsenović

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 381 bytes --]