fmemopen and fseek(fp, 0L, SEEK_END)

[Adhemerval Zanella]

Hi Pietro,

Thanks for raising this up.  I think since was state in comments from the bz6544,
some programs may expect current behavior.  I think for such cases the simple
patch propose in bug report can not be used, but rather we should provide a new
versioned symbol to change its behavior while still providing old way.

One way I see it is to create a new fmemopen_seek (or parametrize it, since it is
static anyway) symbol with different SEEK_END logic and a tie it with the new 
fmemopen symbol.

However since this is not POSIX compliant, we may also just correct it directly.
I'm not sure which is the default position of GLIBC community for such cases.
Any ideas?


On 03-06-2014 12:00, Pietro Cerutti wrote:
> 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
>