[PATCH v2] libio: Fix fmemopen_write on appending condition

[Rocket Ma]

Adhemerval Zanella Netto <adhemerval.zanella@linaro.org> 于2026年3月25日周三 04:26写道：
> I think setbuf is not strictly required here, with this fix fclose does write
> on the input buffer. It also masks a potential issue, as below. I think we
> need to test *all* possible buffer modes.

I know what you mean, but I think this patch should be simple enough to fix only
one issue, we could discuss another patch to test other modes to fix Bug 34006.

> Yes, and I agree with your rationale. The issue is, with this patch,
> fclose in buffered mode (the default) now returns a failure *without*
> setting errno and this is inconsistent.

I tested it in https://sourceware.org/bugzilla/show_bug.cgi?id=34006#c1
I think we could fix it in another patch to leave this patch clean and neat.

> I am not sure if fmemopen_write should hide that less bytes are written
> in the input buffer (thus running 's') or if we should fix it on the
> fwrite (so it only advances its internal position 3 instead of 4 and
> then issues fmemopen_write with s=3 instead of s4).

I do think we should advance s=4 instead of 3 according to POSIX.1-2024.
Or I misunderstand?

> I think we should have the fmemopen size information somewhere in the
> FILE so _IO_file_doallocate can allocate a buffer with a size limit
> instead of a BUFSIZ one.  One we can init the buffer size on __fmemopen,
> but it pessimize memory allocation on FILE creation instead of when
> data is actually done.  Something as below:
>
> It has the size effect of making a fwrite that overflow the input
> buffer to signal the numbers of bytes that will be written in a fflush
> or fclose, instead of silent fail.  But it triggers a regression
> on stdio-common/tst-fmemopen2 because it seems that we do expect this
> for buffer size of 0 (not sure if this test is fully valid though).

I don't think glibc should fail fast on fwrite. I mounted a tmpfs with 4k size,
then write to it with buffered IO, each time 0x1000 and then flush,
here is the result:

fwrite 0x1000 = 0x1000
fflush = 0
fwrite 0x1000 = 0x1000
fclose = 0xffffffffffffffff No space left on device

The source is attached below. In this case, since filesystem FILE
behave like this,
then why should we fail directly on fwrite?

---

int main(void) {
    FILE *fp = fopen("tmpfs/1", "wb");
    setvbuf(fp, NULL, _IOFBF, 0x2200);
    char *spc = malloc(0x2000);
    memset(spc, 'A', 0x2000);
    long rc = fwrite(spc, 1, 0x1000, fp);
    printf("fwrite 0x1000 = %#lx\n", rc);
    rc = fflush(fp);
    printf("fflush = %#lx\n", rc);
    rc = fwrite(spc, 1, 0x1000, fp);
    printf("fwrite 0x1000 = %#lx\n", rc);
    rc = fclose(fp);
    printf("fclose = %#lx %m\n", rc);
    return 0;
}