open_memstream() ‒ NUL injected on seek/write that doesn't bump the size, I think it can't be per POSIX (and other implementations don't)

[наб]

On Wed, Sep 18, 2024 at 08:34:05PM -0400, DJ Delorie wrote:
> fseek() sets the file position.
> 
> After fclose(), the size of the data is the smaller of ... the number of
> bytes between the beginning of the buffer and the current file position
> indicator.
(unclear to me what you're quoting here, but POSIX doesn't say this;
 it only notes the value of *sizep)

> So if you fseek() to the middle of the written data, and fclose(),
> you've truncated the "file".
Yes, but I have /not/ updated the now-one-past-ftell byte to be NUL.
NULs are only supposed to be inserted on when a write extends the buffer (ll. 51168-51171).

If we interpret POSIX to mean that after fflush the valid range is
[*bufp, *bufp + *sizep], then with *sizep = 7, the 8-byte result is
"gamingQe" because I didn't over-write the e.

Now, this is already a very generous-to-glibc interpretation,
because POSIX doesn't actually say where the result... actually is.
To me, as I read this, it /actually/ resides in
  [*bufp, *bufp + max-ever-ftell) + a one-past-the-end NUL
since the buffer is never said to be resized downwards:
whatever *sizep is set to is irrelevant
(it's convenient if you want to terminate the buffer
 at where you left the cursor I suppose),
but has no bearing on the buffer contents.

This makes natural sense if you consider this is a file API,
and files don't magically get truncated (or mangled) because you sought in them.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/libc-alpha/attachments/20240919/c3715a03/attachment.sig>