Re: gnulib portability issues

[Bruno Haible]

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