On 6/20/2022 6:22 AM, Takashi Yano wrote:
> On Mon, 20 Jun 2022 17:59:35 +0900
> Takashi Yano wrote:
>> Isn't this a bug of newlib? Try following code.
>>
>> #include <stdio.h>
>>
>> int main()
>> {
>> 	printf("%d\n", getchar());
>> 	printf("%d\n", feof(stdin));
>> 	printf("%d\n", getchar());
>> 	return 0;
>> }
>>
>> If you press Ctrl-D at the first getchar(), the second getchar()
>> does not return EOF while it does in linux.
>>
>> The following patch seems to resolve the issue.
>>
>> diff --git a/newlib/libc/stdio/refill.c b/newlib/libc/stdio/refill.c
>> index ccedc7af7..843163b7e 100644
>> --- a/newlib/libc/stdio/refill.c
>> +++ b/newlib/libc/stdio/refill.c
>> @@ -47,11 +47,9 @@ __srefill_r (struct _reent * ptr,
>>   
>>     fp->_r = 0;			/* largely a convenience for callers */
>>   
>> -#ifndef __CYGWIN__
>>     /* SysV does not make this test; take it out for compatibility */
>>     if (fp->_flags & __SEOF)
>>       return EOF;
>> -#endif
>>   
>>     /* if not already reading, have to be reading and writing */
>>     if ((fp->_flags & __SRD) == 0)
>>
>> However, I am not sure what this #ifndef __CYGWIN__ is for.
> 
> Ah, I confirmed that System V (Solaris 11.4) behaves like that.
> Does cygwin aim for System V compatibility???

Thanks for tracking this down!

I don't recall any situation in which Cygwin preferred System V compatibility 
over Linux compatibility.  I'm attaching the commit (from November 2004) in 
which the #ifndef __CYGWIN__ was introduced.  There's no indication in the 
commit message as to the reason for the change.  I also didn't see anything 
relevant in the cygwin or cygwin-developers mailing lists from November 2004, 
but I might have missed it.

I think that commit should probably be reverted, but we should wait until 
Corinna is available.  Even though the issue is in newlib code, the code only 
affects Cygwin, so there's probably no need to involve the newlib list.  But 
again, that's Corinna's call.

Ken