Re: FILE * is opaque so now what ?
Theo Buehler <[email protected]> Mon, 20 Jul 2026 20:16:01 +0200
| Newsgroups | gmane.os.openbsd.tech |
|---|---|
| Message-ID | <[email protected]> |
On Mon, Jul 20, 2026 at 11:10:59AM -0400, enh wrote: > if you decide to go in the direction of adding api, note that > glibc/musl/bionic all have <stdio_ext.h> with this kind of thing in > it. specifically in this case: > > /** > * [__fpending(3)](https://man7.org/linux/man-pages/man3/__fpending.3.html) > returns the number of > * bytes in the output buffer. See __freadahead() for the input buffer. > */ > size_t __fpending(FILE* _Nonnull __fp); > > /** > * __freadahead(3) returns the number of bytes in the input buffer. > * See __fpending() for the output buffer. > */ > size_t __freadahead(FILE* _Nonnull __fp); > > in the absence of these, projects like gnulib copy & paste your struct > FILE internals into their code and read/write your fields directly, > making evolution harder. Yes, we saw that for bionic in gnulib. We added these functions for precisely that reason: https://man.openbsd.org/__freading In our testing things worked without gnulib needing to reach into struct FILE (at least in the three dozen copies we have in our ports tree), but for some reason they still decided to do so at least for part of the struct: https://github.com/coreutils/gnulib/blob/e6bb21523280811c17e2c45ebaa75fe5ddef1fda/lib/stdio-impl.h#L146-L155 https://github.com/coreutils/gnulib/commit/e1d738170920b51cb0035bf939dd29e4f7c6d6fb