From: dxforth@gmail.com   
      
   On 26/07/2025 8:41 pm, Anton Ertl wrote:   
   > dxf  writes:   
   >> ANS seems pedantic on EOF returning both u2=0 and   
   >> flag=0.  The TC reiterated this in response to an RFI.  But why?  Who   
   >> checks u2 for EOF?   
   >   
   > Reporting EOF only when the input has been exhausted before READ-LINE   
   > means that there is no special handling needed for the last line   
   > (assuming you want to process it the same way as the other lines).   
      
   EOF is reported by flag = false.  There was no need to return u2 = 0.   
   There's no function for it AFAIK.   
      
   >> Omitted from the ANS spec is any mention of EOF characters for systems   
   >> that employ it e.g. CP/M and MS-DOS.   
   >   
   > That's in line with the way that the standard deals with different   
   > newline representations: It does not mention them in the normative   
   > part, exactly because they are different and therefore problematic to   
   > standardize.   
   >   
   > For EOF it's the same.  There's a way to report EOF no matter how EOF   
   > is represented in the OS, but no standard way to find out anything   
   > about the representation.   
      
   That's fine if the argument is users don't need to know.   
      
   >> And if READ-LINE encounters such   
   >> there should be a way to report it.   
   >   
   > If you think that the existing EOF handling is insufficient, make a   
   > proposal.  And make a good case why you consider the existing EOF   
   > handling insufficient.   It has been sufficient for me up to now.   
      
   I've resolved it by adding a variable CPMEOF and having READ-LINE set   
   it when it finds one.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)