[tz] Re: 2025c zic.c calls fflush(3) on read only file pointer.

Dec. 18, 2025


      On Thu, Dec 18, 2025 at 3:04 PM Florian Weimer <fweimer@redhat.com> wrote:
...
* enh via tz:
...
does anyone implement the ungetc() part or am i misunderstanding what
that's trying to say?
#include <stdio.h>
int main() {
 FILE* fp = fopen("/tmp/x.c", "r");
 ungetc('x', fp);
 printf("%c\n", fgetc(fp));
 fclose(fp);
fp = fopen("/tmp/x.c", "r");
 ungetc('x', fp);
 fflush(fp);
 printf("%c\n", fgetc(fp));
 fclose(fp);
return 0;
}
where this file is /tmp/x.c gives me x and # whether or not the flush
is there, for both glibc and macOS.
Not sure if this is what you mean.  We changed glibc fairly recently:
commit 377e9733b50ce41e496c467ddcc112f73c88f3bd
Author: Joseph Myers <josmyers@redhat.com>
Date:   Tue Jan 28 19:38:27 2025 +0000
ah, i should probably have said "Debian GLIBC 2.41-12+gl0" rather than
just "glibc".

the test in that sha does look very like my test, even down to the
input starting with "#include" :-)

presumably yet another case where posix just copied down what solaris
did rather than checking what everyone was actually doing.
...
Fix fflush after ungetc on input file (bug 5994)
As discussed in bug 5994 (plus duplicates), POSIX requires fflush
    after ungetc to discard pushed-back characters but preserve the file
    position indicator.  For this purpose, each ungetc decrements the file
    position indicator by 1; it is unspecified after ungetc at the start
    of the file, and after ungetwc, so no special handling is needed for
    either of those cases.
This is fixed with appropriate logic in _IO_new_file_sync.  I haven't
    made any attempt to test or change things in this area for the "old"
    functions; the case of files using mmap is addressed in a subsequent
    patch (and there seem to be no problems in this area with files opened
    with fmemopen).
Tested for x86_64.
Thanks,
Florian