public inbox for glibc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug libc/1996] New: open_memstream() and seek past end of buffer
@ 2005-12-08 15:33 michael dot kerrisk at gmx dot net
2006-04-24 22:05 ` [Bug libc/1996] " rsa at us dot ibm dot com
` (3 more replies)
0 siblings, 4 replies; 5+ messages in thread
From: michael dot kerrisk at gmx dot net @ 2005-12-08 15:33 UTC (permalink / raw)
To: glibc-bugs
The info page for open_memstream() says:
You can move the stream's file position with `fseek' or `fseeko'
(*note File Positioning::). Moving the file position past the end
of the data already written fills the intervening space with
zeroes.
However, this is not so. When the program below is run, the
following output is produced:
$ ./a.out
ftell() before = 0
fseek error: Success
ftell() after = 0
ptr=0x804a180 size=3
Either the implementation or the documentation appears to be broken.
#define _GNU_SOURCE
#include <assert.h>
#include <stdio.h>
int main(int argc, char *argv[])
{
FILE *output;
size_t size;
char *ptr;
long l;
output = open_memstream(&ptr, &size);
assert(output != NULL);
printf("ftell() before = %ld\n", ftell(output));
l = fseek(output, 50, SEEK_END);
if (l != 0) perror("fseek error");
printf("ftell() after = %ld\n", ftell(output));
fprintf(output, "xxx");
fflush(output);
printf("ptr=%p size=%ld\n", ptr, (long) size);
return 0;
}
--
Summary: open_memstream() and seek past end of buffer
Product: glibc
Version: 2.3.5
Status: NEW
Severity: normal
Priority: P2
Component: libc
AssignedTo: drepper at redhat dot com
ReportedBy: michael dot kerrisk at gmx dot net
CC: glibc-bugs at sources dot redhat dot com
http://sourceware.org/bugzilla/show_bug.cgi?id=1996
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug libc/1996] open_memstream() and seek past end of buffer
2005-12-08 15:33 [Bug libc/1996] New: open_memstream() and seek past end of buffer michael dot kerrisk at gmx dot net
@ 2006-04-24 22:05 ` rsa at us dot ibm dot com
2006-04-24 23:06 ` michael dot kerrisk at gmx dot net
` (2 subsequent siblings)
3 siblings, 0 replies; 5+ messages in thread
From: rsa at us dot ibm dot com @ 2006-04-24 22:05 UTC (permalink / raw)
To: glibc-bugs
------- Additional Comments From rsa at us dot ibm dot com 2006-04-24 22:05 -------
Michael,
Your call:
l = fseek(output, 50, SEEK_END);
is failing with l == -1, but there is no errno being set. I'm taking a look at
the fseek() function. I think it is returning from CHECK_FILE() with -1 and no
errno. This is probably because you're trying to seek to the end of an empty
stream at this point. I'll investigate more.
--
http://sourceware.org/bugzilla/show_bug.cgi?id=1996
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug libc/1996] open_memstream() and seek past end of buffer
2005-12-08 15:33 [Bug libc/1996] New: open_memstream() and seek past end of buffer michael dot kerrisk at gmx dot net
2006-04-24 22:05 ` [Bug libc/1996] " rsa at us dot ibm dot com
@ 2006-04-24 23:06 ` michael dot kerrisk at gmx dot net
2006-04-25 21:22 ` rsa at us dot ibm dot com
2006-08-14 22:16 ` drepper at redhat dot com
3 siblings, 0 replies; 5+ messages in thread
From: michael dot kerrisk at gmx dot net @ 2006-04-24 23:06 UTC (permalink / raw)
To: glibc-bugs
------- Additional Comments From michael dot kerrisk at gmx dot net 2006-04-24 23:06 -------
Subject: Re: open_memstream() and seek past end of buffer
Hi Ryan,
> Your call:
>
> l = fseek(output, 50, SEEK_END);
>
> is failing with l == -1, but there is no errno being set. I'm taking a
> look at the fseek() function. I think it is returning from CHECK_FILE()
> with -1 and no errno. This is probably because you're trying to seek to
> the end of an empty stream at this point. I'll investigate more.
I'm not quite sure what you mean by its "my call". Yes, fseek() is
failing with errno not set, but the point is that *according to the
documentation* I should be able to successfully perform move to some point
past the endd of stream:
You can move the stream's file position with `fseek' or `fseeko'
(*note File Positioning::). Moving the file position past the end
of the data already written fills the intervening space with
zeroes.
Cheers,
Michael
--
http://sourceware.org/bugzilla/show_bug.cgi?id=1996
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug libc/1996] open_memstream() and seek past end of buffer
2005-12-08 15:33 [Bug libc/1996] New: open_memstream() and seek past end of buffer michael dot kerrisk at gmx dot net
2006-04-24 22:05 ` [Bug libc/1996] " rsa at us dot ibm dot com
2006-04-24 23:06 ` michael dot kerrisk at gmx dot net
@ 2006-04-25 21:22 ` rsa at us dot ibm dot com
2006-08-14 22:16 ` drepper at redhat dot com
3 siblings, 0 replies; 5+ messages in thread
From: rsa at us dot ibm dot com @ 2006-04-25 21:22 UTC (permalink / raw)
To: glibc-bugs
------- Additional Comments From rsa at us dot ibm dot com 2006-04-25 21:22 -------
Alright, found the problem.
open_memstream defines _IO_str_seekoff as the function to call when fseek() is
invoked against a stream opened with open_memstream. In:
libio/strops.c (_IO_str_seekoff)
line 275:
if (offset < 0 || (_IO_ssize_t) offset > cur_size)
return EOF;
In your case offset == 50, and cur_size == 0. Since the open_memstream()
function uses _IO_str_seekoff() and that function doesn't allow seeking beyond
the end of the data already written to the stream then this would indicate that
the documentation is wrong with regard to the current behavior.
A fix for this would be to have open_memstream() provide an overridden fseek
function which allows seeking beyond the end of the stream up to the end of the
buffer. I'm not sure this is desireable but I don't see why it isn't possible
since the beginning buffer size created by open_memstream is _G_BUFSIZE (8192).
--
http://sourceware.org/bugzilla/show_bug.cgi?id=1996
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug libc/1996] open_memstream() and seek past end of buffer
2005-12-08 15:33 [Bug libc/1996] New: open_memstream() and seek past end of buffer michael dot kerrisk at gmx dot net
` (2 preceding siblings ...)
2006-04-25 21:22 ` rsa at us dot ibm dot com
@ 2006-08-14 22:16 ` drepper at redhat dot com
3 siblings, 0 replies; 5+ messages in thread
From: drepper at redhat dot com @ 2006-08-14 22:16 UTC (permalink / raw)
To: glibc-bugs
------- Additional Comments From drepper at redhat dot com 2006-08-14 22:15 -------
I checked in a patch.
--
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
http://sourceware.org/bugzilla/show_bug.cgi?id=1996
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2006-08-14 22:16 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-12-08 15:33 [Bug libc/1996] New: open_memstream() and seek past end of buffer michael dot kerrisk at gmx dot net
2006-04-24 22:05 ` [Bug libc/1996] " rsa at us dot ibm dot com
2006-04-24 23:06 ` michael dot kerrisk at gmx dot net
2006-04-25 21:22 ` rsa at us dot ibm dot com
2006-08-14 22:16 ` drepper at redhat dot com
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).