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: Paolo Bonzini
Subject: Re: Why require SLOW_BUT_NO_HACKS for stubs?
Date: Sat, 23 Jun 2012 16:56:34 +0200

On Sun, Jun 17, 2012 at 11:40 PM, Bruno Haible <address@hidden> wrote:
> 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.

You can add a test program that detects an unported-to libc.  So they
would get a slow program but also a make check failure.

>> - #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.

Indeed, it is only correct to use this replacement in close_stdin.

Paolo



reply via email to

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