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

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

[mtk.manpages at gmail dot com]

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

Michael Kerrisk <mtk.manpages at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mtk.manpages at gmail dot
                   |                            |com

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

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

[mtk.manpages at gmail dot com]

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

Michael Kerrisk <mtk.manpages at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |eblake at redhat dot com

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

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

[mtk.manpages at gmail dot com]

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

--- Comment #5 from Michael Kerrisk <mtk.manpages at gmail dot com> 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 .
]]

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

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

[jackie.rosen at hushmail dot com]

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

Jackie Rosen <jackie.rosen at hushmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jackie.rosen at hushmail dot com

--- Comment #6 from Jackie Rosen <jackie.rosen at hushmail dot com> ---
*** Bug 260998 has been marked as a duplicate of this bug. ***
Seen from the domain http://volichat.com
Page where seen: http://volichat.com/adult-chat-rooms
Marked for reference. Resolved as fixed @bugzilla.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

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

[schwab at sourceware dot org]

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

Andreas Schwab <schwab at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|jackie.rosen at hushmail dot com   |

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[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.