Shriramana Sharma wrote:
> Hello.
>
> Here's the bug report that bashbug was unable to send because it did not
> find something called rmail on my system. I hope these bugs can be fixed.
Thanks for the report. The bash completion system is developed and
distributed separately from bash. It uses
Configuration Information [Automatically generated, do not change]:
Machine: i386
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i386'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i386-pc-linux-gnu'
-DCONF_VENDOR='pc' -DSHELL -DHAVE_CONFIG_H -I. -I../bash -I../
Configuration Information [Automatically generated, do not change]:
Machine: i686
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/local/share/locale'
-DPACKAGE
[EMAIL PROTECTED] writes:
> 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';
> ;;;
> }
>
[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)fi
Matthew Woehlke <[EMAIL PROTECTED]> writes:
> 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 gues
Andreas Schwab wrote:
Matthew Woehlke writes:
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'
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Matthew Woehlke on 3/23/2007 1:38 PM:
> Huh? I never said anything about ssize_t, I said SSIZE_MAX which appears
> to be guaranteed by POSIX to be at least 32 *kilobytes*,
SSIZE_MAX is guaranteed to be the maximum value that fits in ssize
Eric Blake wrote:
According to Matthew Woehlke on 3/23/2007 1:38 PM:
Huh? I never said anything about ssize_t, I said SSIZE_MAX which appears
to be guaranteed by POSIX to be at least 32 *kilobytes*,
SSIZE_MAX is guaranteed to be the maximum value that fits in ssize_t.
Again, if your ssize_t is
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Matthew Woehlke on 3/23/2007 2:40 PM:
>>
>> SSIZE_MAX is guaranteed to be the maximum value that fits in ssize_t.
>> Again, if your ssize_t is smaller than 32 bits, your platform has other
>> issues. Just because POSIX allows ssize_t to b
Eric Blake wrote:
According to Matthew Woehlke on 3/23/2007 2:40 PM:
SSIZE_MAX is guaranteed to be the maximum value that fits in ssize_t.
...that "fits", or that "may be stored in"?
Again, if your ssize_t is smaller than 32 bits, your platform has other
issues. Just because POSIX allows ss
Matthew Woehlke <[EMAIL PROTECTED]> writes:
> Hmm... well then I guess this is broken:
> /usr/include/limits.h:#define SSIZE_MAX53248/* max single I/O
> size, 52K */
The creativity of system designers always amazes me. :-(
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECT
12 matches
Mail list logo
