This is the mail archive of the
libc-hacker@sourceware.cygnus.com
mailing list for the glibc project.
Re: libio fflush() bug
- To: kukuk@weber-eb.uni-paderborn.de
- Subject: Re: libio fflush() bug
- From: Ulrich Drepper <drepper@cygnus.com>
- Date: 11 Aug 1998 09:11:55 -0700
- Cc: libc-hacker@cygnus.com
- References: <98080719361700.25532@voyager>
- Reply-To: drepper@cygnus.com (Ulrich Drepper)
Thorsten Kukuk <kukuk@weber-eb.uni-paderborn.de> writes:
> I have found a big problem. If you do fseek/fread/fflush, the file pointer
> is set to the end of the file. If you don't call fseek, the pointer is set
> correct to the next byte after the last read one.
I've looked at this closer and the first thing I came across is a
kernel bug is the 2.1.xxx kernels. Linus already changed his tree.
The problem is in fs/read_write.c:109:
retval = (int)offset & INT_MAX;
This should read
retval = (int)offset;
In case of an error the & removes the MSB and therefore the libc does
not recognize this as an error.
But even with this the result is a bit suspecious (though Thorsten's
test case works now):
_llseek(3, 0, {0}, SEEK_SET) = 0
read(3, "#include <stdio.h>\n\nint\nmain "..., 4096) = 405
_llseek(3, -401, 0xbffff690, SEEK_CUR) = -1 EINVAL (Invalid argument)
Why should the second _llseek fail?
(The above result were produced with a new version of strace which
understands _llseek and which I"ll upload to
ftp.cygnus.com/pub/home/drepper in a few minutes).
--
---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace
Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com `------------------------