[Bug libc/6544] New: fseek(..., 0, SEEK_END) doesn't work as it should on fmemopen's FILE

[Bug libc/6544] New: fseek(..., 0, SEEK_END) doesn't work as it should on fmemopen's FILE

[witekfl at poczta dot onet dot pl]

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:

-- 
           Summary: fseek(..., 0, SEEK_END) doesn't work as it should on
                    fmemopen's FILE
           Product: glibc
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
        AssignedTo: drepper at redhat dot com
        ReportedBy: witekfl at poczta dot onet dot pl
                CC: glibc-bugs at sources dot redhat dot com


http://sourceware.org/bugzilla/show_bug.cgi?id=6544

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/6544] fseek(..., 0, SEEK_END) doesn't work as it should on fmemopen's FILE

[witekfl at poczta dot onet dot pl]

------- Additional Comments From witekfl at poczta dot onet dot pl  2008-05-22 06:29 -------
Created an attachment (id=2751)
 --> (http://sourceware.org/bugzilla/attachment.cgi?id=2751&action=view)
Load ZIP file into memory and decompress the first entry

Real code that failed.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=6544

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/6544] fseek(..., 0, SEEK_END) doesn't work as it should on fmemopen's FILE

[witekfl at poczta dot onet dot pl]

------- Additional Comments From witekfl at poczta dot onet dot pl  2008-05-22 06:31 -------
Created an attachment (id=2752)
 --> (http://sourceware.org/bugzilla/attachment.cgi?id=2752&action=view)
Patch.


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=6544

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/6544] fseek(..., 0, SEEK_END) doesn't work as it should on fmemopen's FILE

[drepper at redhat dot com]

------- Additional Comments From drepper at redhat dot com  2008-08-14 06:34 -------
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.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED


http://sourceware.org/bugzilla/show_bug.cgi?id=6544

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/6544] fseek(..., 0, SEEK_END) doesn't work as it should on fmemopen's FILE

[ebb9 at byu dot net]

------- Additional Comments From ebb9 at byu dot net  2008-08-14 16:53 -------
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


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=6544

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.