From: muta...@gmail.com   
      
   On Wednesday, October 13, 2021 at 11:16:00 AM UTC+11, Scott Lurndal wrote:   
      
   > I posted a C code fragment from an existing NNTP client   
   > that uses 'fgets' and 'fputs' on a line-oriented stream   
   > (associated with a TCP connection). The C library handles   
   > it just fine. There are a half-dozen or more open source   
   > C libraries around that you can download and see how they   
   > do it.   
      
   I thought of how it could be done - the fact that the stream   
   is line buffered would cause the C library to do reads of   
   1 byte.   
      
   Only if a stream is fully buffered would it do a fixed size read.   
      
   But this leads to a different problem - the C90 standard says:   
      
   When opened, a stream is fully buffered if and only if it can be   
   determined not to refer to an interactive device.   
      
   That sounds like it has Unix origins. I'm not sure that Windows   
   and MVS provide calls to neatly determine whether a device can   
   be fully buffered or not. I'm not sure that that is necessarily known   
   even at the hardware level.   
      
   This is a philosophy question. I'm not just after someone else's   
   implementation. I'd like to derive the philosophy from first   
   principles, and I'm willing to change the C90 standard if it is   
   insufficient.   
      
   I'm wondering whether an application should be the one to   
   signal it is wanting to do interaction at the byte or line level   
   rather than being left to the C library to figure it out for itself.   
   With files being fully-buffered by default, which is the normal   
   case for disk files.   
      
   I'm talking about files other than stdin/stdout/stderr which I   
   am happy to have as line-buffered by default.   
      
   BFN. Paul.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)