bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Why require SLOW_BUT_NO_HACKS for stubs?


From: Bruno Haible
Subject: Re: Why require SLOW_BUT_NO_HACKS for stubs?
Date: Sun, 17 Jun 2012 23:40:51 +0200
User-agent: KMail/4.7.4 (Linux/3.1.10-1.9-desktop; KDE/4.7.4; x86_64; ; )

Isaac Dunham wrote:
> > The test as it stands is "error out on unsupported platforms unless
> > user specifies to use slow method".
> > My proposal is "On unsupported platforms, use the slow method instead
> > of erroring out."

If we did this, nobody would report to bug-gnulib (or to the libc maintainer)
the need to port the functions. You would get a slow or buggy program
instead.

Paolo Bonzini wrote:
> @@ -84,10 +85,10 @@ 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."
> +  /* This implementation is correct on any ANSI C platform.  It is just
> +     awfully slow.  */
> +  return freading(fp) && !feof(fp);
> + #warning "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."
>  #endif
>  }

This alternative code is not correct. On a stream freshly opened for reading
it returns 1 where is should return 0 instead.

Bruno




reply via email to

[Prev in Thread] Current Thread [Next in Thread]