This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
| Other format: | [Raw text] | |
Hello,
as discussed on FreeNode/#glibc, I'm raising concerns as to how fmemopen
handles a fseek to offset 0 from SEEK_END. The issue was already
discussed in [1]. I'll summarize.
#include <stdio.h>
int main()
{
char buf[] = "Hello";
buf[3] = '\0';
FILE * f = fmemopen((void *)buf, sizeof(buf), "r");
fseek(f, 0, SEEK_END);
printf("%ld\n", ftell(f));
fclose(f);
return 0;
}
This prints 3 with glibc, but should print 6 according to POSIX [2],
quoting:
"The stream shall also maintain the size of the current buffer contents;
use of fseek() or fseeko() on the stream with SEEK_END shall seek
relative to this size. For modes r and r+ the size shall be set to the
value given by the size argument."
I suggest to modify glibc's fmemopen implementation *not to* behave
differently depending on whether the stream was opened in binary mode
when fseek'ing wrt SEEK_END.
Comments?
[1] https://sourceware.org/bugzilla/show_bug.cgi?id=6544
[2] http://pubs.opengroup.org/onlinepubs/9699919799/functions/fmemopen.html
--
Pietro Cerutti
The FreeBSD Project
gahr@FreeBSD.org
PGP Public Key:
http://gahr.ch/pgp
Attachment:
pgpGZgoJnV01t.pgp
Description: PGP signature
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |