bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: source(builtin) and read(2)


From: Matthew Woehlke
Subject: Re: source(builtin) and read(2)
Date: Fri, 23 Mar 2007 12:04:30 -0500
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.10) Gecko/20070221 Thunderbird/1.5.0.10 Mnenhy/0.7.4.0

hooanon05@yahoo.co.jp wrote:
The source builtin command reads the given file after getting its size
by fstat(2). But bash doen't check the read bytes which is a return
value of read(2).

builtins/evalfile.c
_evalfile()
{
  fd = open (filename, O_RDONLY);
  fstat (fd, &finfo);
  file_size = (size_t)finfo.st_size;
  string = (char *)xmalloc (1 + file_size);
  result = read (fd, string, file_size);
  string[result] = '\0';
        ;;;
}
(I checked bash-3.0 too)

When the file size is very large or the filesystem is poor, the read(2)
systemcall may not read all of the file. In this case, the return value
will be shorter than the requested bytes.

Um. In fact, it is also an *ERROR* (i.e. read() will fail outright with - IIRC - EINVAL) to try to read more than SSIZE_MAX bytes at once. Many, but not all, systems define SSIZE_MAX to be a very large value, but it may be as small as 32k. I guess I've never tried to source an autoconf configure script on such a system.

From 'man 2 read' (on Linux):
"If count is greater than SSIZE_MAX, the result is unspecified."

In other words, the above code is broken. That said, I didn't see a problem doing 'source ./configure' on make-3.81's configure script (400+kb), but I also have a version of bash that is very likely patched around this issue.

See also discussion on the gzip mailing list (look for SSIZE_MAX), and one other (gawk, I think).

--
Matthew
Excessive obscurity: -5





reply via email to

[Prev in Thread] Current Thread [Next in Thread]