[EMAIL PROTECTED] 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
_______________________________________________
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
