Bug 6544 - fseek(..., 0, SEEK_END) doesn't work as it should on fmemopen's FILE
Summary: fseek(..., 0, SEEK_END) doesn't work as it should on fmemopen's FILE
Status: RESOLVED FIXED
Alias: None
Product: glibc
Classification: Unclassified
Component: libc (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: ---
Assignee: Ulrich Drepper
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-05-22 06:26 UTC by witekfl
Modified: 2014-07-03 11:30 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:
fweimer: security-


Attachments
Load ZIP file into memory and decompress the first entry (1005 bytes, application/x-bzip2)
2008-05-22 06:29 UTC, witekfl
Details
Patch. (194 bytes, patch)
2008-05-22 06:31 UTC, witekfl
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description witekfl 2008-05-22 06:26:29 UTC
fmemopen_seek in case of SEEK_END set the seek position on the first '\0' char
what is wrong. This way fmemopen is unusable with binary data.
I tried to use fmemopen with zziplib library to open a ZIP file which was
already loaded into memory, but it failed. With the patch below it works fine. 


--- glibc-2.8/libio/fmemopen.c.old      2008-05-21 23:40:18.000000000 +0200
+++ glibc-2.8/libio/fmemopen.c  2008-05-21 23:42:51.000000000 +0200
@@ -165,7 +165,7 @@ fmemopen_seek (void *cookie, _IO_off64_t
       break;

     case SEEK_END:
-      np = c->maxpos - *p;
+      np = c->size - *p;
       break;

     default:
Comment 1 witekfl 2008-05-22 06:29:43 UTC
Created attachment 2751 [details]
Load ZIP file into memory and decompress the first entry

Real code that failed.
Comment 2 witekfl 2008-05-22 06:31:30 UTC
Created attachment 2752 [details]
Patch.
Comment 3 Ulrich Drepper 2008-08-14 06:34:58 UTC
The patch cannot be used as is.  Existing code might expect the current behavior.

Instead I implement a binary mode, selected through 'b' in the mode string.  It
seems this is done in your code so you should not have to make any changes.  In
the binary mode we do the search as you proposed and writes don't add a NUL byte.
Comment 4 Eric Blake 2008-08-14 16:53:48 UTC
POSIX 200x is standardizing fmemopen with semantics that match neither the
original implementation, nor your new binary mode (in particular, the POSIX
wording states concerning the mode argument "The character 'b' shall have no
effect").  I also raised some questions as to whether glibc's fmemopen is buggy
in relation to other stream behavior:

https://www.opengroup.org/sophocles/show_mail.tpl?CALLER=show_archive.tpl&source=L&listname=austin-group-l&id=10782
Comment 5 Michael Kerrisk 2012-04-28 03:36:15 UTC
Since the addition of binary mode appears to have been a silent change to the ABI, I've noted this in the man page, under bugs:

[[
The glibc 2.9 addition of "binary" mode for
.BR fmemopen ()
silently changed the ABI: previously,
.BR fmemopen ()
ignored \(aqb\(aq in
.IR mode .
]]
Comment 6 Jackie Rosen 2014-02-16 18:23:30 UTC Comment hidden (spam)