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:
Created attachment 2751 [details] Load ZIP file into memory and decompress the first entry Real code that failed.
Created attachment 2752 [details] Patch.
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.
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
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 . ]]
*** 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.