Hi Paul, > > They're purposefully opaque so that they can be changed if an > > alternate implementation proves better. > > Dragonfly BSD attacked this problem by supplying a > function __sreadahead that returns the value in question. > Perhaps musl could do something similar? That would fix > the problem while preserving opacity.
Yes, exactly. > Another possibility is something like the following patch, > which may fix this particular problem, though I expect that there are > other problems with the opacity that would still be in > there somewhere. > > Also, I don't like this patch because it adds runtime overhead > in the non-musl case, but presumably this could be fixed. > (Right now I'm just trying to think through possible solutions.) > > diff --git a/lib/freadahead.c b/lib/freadahead.c > index 2ba8b34..db6b68b 100644 > --- a/lib/freadahead.c > +++ b/lib/freadahead.c > @@ -84,10 +84,7 @@ freadahead (FILE *fp) > if (fp->state == 4 /* WR */ || fp->rp >= fp->wp) > return 0; > return fp->wp - fp->rp; > -#elif defined SLOW_BUT_NO_HACKS /* users can define this */ > - abort (); > - return 0; > #else > - #error "Please port gnulib freadahead.c to your platform! Look at the > definition of fflush, fread, ungetc on your system, then report this to > bug-gnulib." > + return -1; > #endif > } I don't much like this patch because it gives up too early. freadahead() is much like fpending(): Every platform has a reasonable implementation of it. If fpending() returned some "don't know" indicator, some programs would sensibly misbehave. Likewise for freadahead(). Bruno
