[Bug stdio/26557] New: Incorrect behavior with open_memstream in recent version(s) of glibc

[Bug stdio/26557] New: Incorrect behavior with open_memstream in recent version(s) of glibc

[trt at sas dot com]

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

            Bug ID: 26557
           Summary: Incorrect behavior with open_memstream in recent
                    version(s) of glibc
           Product: glibc
           Version: 2.28
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: stdio
          Assignee: unassigned at sourceware dot org
          Reporter: trt at sas dot com
  Target Milestone: ---

Created attachment 12812
  --> https://sourceware.org/bugzilla/attachment.cgi?id=12812&action=edit
memstream-test.c

The attached memstream-test.c gives expected fseek() behavior on streams
created with fopen() and with fmemopen(), and also with open_memstream in glibc
2.12 and 2.17.  But in glibc 2.28 an open_memstream() gives incorrect behavior

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

[Bug stdio/26557] Incorrect behavior with open_memstream in recent version(s) of glibc

[trt at sas dot com]

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

--- Comment #1 from Tom Truscott <trt at sas dot com> ---
Correction: open_memstream() gives incorrect behavior in all those glibc (2.12,
2.17, 2.28, and also 2.31). The incorrect behavior varies.

Also, fmemopen() gave incorrect behavior in older glibc, but it seems okay now
and our only concern is with open_memstream().

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

[Bug stdio/26557] Incorrect behavior with open_memstream in recent version(s) of glibc

[pipcet at gmail dot com]

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

pipcet at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pipcet at gmail dot com

--- Comment #2 from pipcet at gmail dot com ---
I'm seeing this as well, I believe:

When the FILE *returned by open_memstream is closed, the buffer that is
returned is truncated to be as large as the current file offset, not the length
of the data that has been written (and also not the actual size of the buffer
that has been allocated).

Furthermore, fseek (file, 0, SEEK_END) does not seek to the end of the written
buffer.

It's possible this behavior is documented in the standard, but it's not
documented in the manpage.

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

[Bug stdio/26557] Incorrect behavior with open_memstream in recent version(s) of glibc

[carlos at redhat dot com]

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

Carlos O'Donell <carlos at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://bugzilla.redhat.com
                   |                            |/show_bug.cgi?id=1875596
                 CC|                            |carlos at redhat dot com

--- Comment #3 from Carlos O'Donell <carlos at redhat dot com> ---
We started an RFC in 20220 about open_memstream behaviour to harmonize:
https://www.openwall.com/lists/libc-coord/2020/09/24/1

There is an Austin Group ticket open for clarification:
https://www.austingroupbugs.net/view.php?id=1406

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