On Thu, Dec 18, 2025 at 3:04 PM Florian Weimer <[email protected]> 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 <[email protected]> > 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 >
