[patch, libgfortran] PR31052 Bad IOSTAT values when readings NAMELISTs past EOF

[Jerry DeLisle]

Steve Kargl wrote:
> On Sat, Mar 10, 2007 at 08:57:19AM -0800, Jerry DeLisle wrote:
>> Steve Kargl wrote:
>>> On Fri, Mar 09, 2007 at 11:45:33PM -0800, Jerry DeLisle wrote:
>>>> I would rather keep the patch as I have it and leave dev_null.f90 alone.  
>>>> In this case we are user proofing.  st_rewind is simply seeking to 
>>>> position zero of the file and then resetting all the internal libgfortran 
>>>> accounting stuff. /dev/null is a "special seekable" file.
>>>>
>>>> I have also tested this on an empty file and it works OK for that.  The 
>>>> adjustment in the patch occurs well after all the rewind stuff is done.
>>>>
>>>> I will await approval.
>>>>
>>> I have you tested with /dev/zero and /dev/random?
>>>
>> I had not, but now I have and the test_endfile does not "work" for a rewind 
>> on these.  In other words, I get an EOF condition on a read following a 
>> rewind.  It seems that the whole concept is askew.  The /dev/null is 
>> defined to always give an EOF on a read.  The others should never give an 
>> EOF.
>>
>> I want to give this some thinking time.  The OS should give the correct 
>> response and rewind should ideally have no effect.  I think I should 
>> address why it does have an effect now, with or without test_endfile.
>>
>> In the interim, I would like to fix the original PR by eliminating 
>> test_endfile and open a new PR related to the behavior of these special 
>> devices.
>>
>> Is there agreement on this?
>>
> 
> Yes.
> 
> The handling of special files (and fifo and pipes) is probably
> a messy system dependent pit.

Well, I completely removed the test_endfile function found in open.c and all of 
its invocations in several places.  I removed the prototype from io.h.

Regression tested, NIST tested, many io tested with some programs I have 
collected.  All pass with flying colors.  I suspect we worked our way out of 
needing it with other patches until it was redundant and no longer needed.  The 
only place it was needed is in st_rewind to handle that one odd case for dev/null.

Removing the call to rewind in the test case dev_null.f90 and that test case 
passes fine with the expected behavior, EOF on a read.

I will go ahead and work up the test case for PR31052 and resubmit a final patch.

Regards,

Jerry