Re: FILE * is opaque so now what ?

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.

given the "binaries bought with actual money" android ecosystem,
android's probably still another ten years away from being able to
meaningfully change struct FILE because these kinds of hacks are
fairly commonplace...

On Thu, Jul 16, 2026 at 11:01 AM Theo Buehler <[email protected]> wrote:
>
> On Thu, Jul 16, 2026 at 04:57:09PM +0200, Marc Espie wrote:
> > I've run into a language (unicon) that wants to do FILE* level polls
> > by first checking whether there's something stored in the internal
> > FILE* read buffer.
> >
> > Specifically, checking whether that the old f->_r field is zero or not.
>
> Not portable, but see __freadptr(3)
>
> >
> > Now, I know of ZERO ways to do that check portably.
> >
> > Do we have something like that anywhere ? it looks like a legitimate
> > question, and I'd hate to have the only answer be "hey, put everything
> > in non-buffered mode and get direct access to the fds"
> >
> >
> > (for now, I've disabled that part of the code entirely)
> >
> >
> > As far as libc is concerned, what I now is fgetc + ungetc, which tends to
> > be blocking and hence not at all what we want ?
> >
>