From: muta...@gmail.com   
      
   On Monday, November 1, 2021 at 5:16:45 AM UTC+11, muta...@gmail.com wrote:   
      
   > > >Regardless, would you expect a C library to have different paths   
   > > >for dealing with block devices vs character devices?   
   >   
   > > The entire point of Unix was to treat all files as simple streams   
   > > of bytes. The C library didn't give a shit about the file type.   
   > > The Operating System ensured that all files (disk, tape, terminal,   
   > > card readers, line printers, et alia) appear to the application as   
   > > a simple stream of bytes.   
      
   > I thought the goal was for the application to get a simple   
   > stream of bytes, not necessarily the C library.   
   >   
   > For the C library, I think/guess that it should be aware of   
   > whether it is dealing with a block device or a character   
   > device. If it is dealing with a block device, then, for instance,   
   > it shouldn't issue a write() syscall until it has a buffer of   
   > suitable size for that device. Similarly, it should be conscious   
   > when seeking that it is seeking to a block boundary, and   
   > reading should be done of an entire block.   
      
   I think I know what was bugging me.   
      
   The Unix implementation of the C library doesn't need to   
   care about blocks - Unix will take care of that.   
      
   My situation is that I will have a C library directly doing BIOS   
   calls (and maybe UEFI calls), not OS calls, so I'm the one that   
   needs to deal with the block devices, specifically sector reads   
   and writes, so I need to use the "MVS" flavor of PDPCLIB,   
   which is incorrectly named "MVS" and should instead have   
   been called "block".   
      
   I think.   
      
   BFN. Paul.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)