From: james.harris.1@gmail.com   
      
   On 19/07/2021 10:23, muta...@gmail.com wrote:   
   > On Sunday, July 18, 2021 at 11:19:53 PM UTC+10, James Harris wrote:   
      
   ...   
      
   >>>> There's nothing wrong with fwrite (if one is emulating Unix) and I'm not   
   >>>> suggesting renaming it.   
   >>>   
   >>> Why did you mention Unix? This has nothing to do with   
   >>> Unix, other than it inspired the name vsyscall.   
   >   
   >> fwrite is specified by POSIX, although I should probably have   
   >> generalised Linux into POSIX rather than just into Unix.   
   >   
   > That transfers the question - why did you mention POSIX?   
   > This has nothing to do with POSIX.   
   >   
   > fwrite is specified by C90.   
      
   Is it? That's surprising. I could imagine it being mentioned as being   
   part of a/the standard C library  but I personally wouldn't have thought   
   it would be part of the language and I could imagine some   
   implementations of C not having it. No matter.   
      
   I mentioned Posix because fwrite is an OS call which Posix incuded in   
   the standard (Posix being a portable OS interface and fwrite being part   
   of an OS interface).   
      
    From the little I know of clib it seems to be a library in which a   
   whole load of different things have been lumped together, most notably   
   both language support and OS-interfacing support. The clue is in the   
   name! I could imagine a "language" library including routines to support   
   the language - things like supporting routines and extra data structures   
   - but would have thought there would be additional OS-interfacing   
   libraries. It's possible that clib includes the lot simply for   
   historical reasons, so as not to break older code.   
      
   >   
   >>> Yes, I want something like this. And where you say "carries   
   >>> out the write" - actually I want every function involved in   
   >>> that to be called "fwrite" too. Whether it is writing to a   
   >>> particular sector of a FAT partition, or the FAT infrastructure   
   >>> doing a special-BIOS-layer fwrite to write to a section of disk 0x80.   
   >   
   >> I can't think why you might want multiple levels of software all to have   
   >> the same name. I'm not arguing that you should do otherwise. That's your   
   >> choice. But it does seem unnecessary and confusing.   
   >   
   > I think it's very neat. If you want to write 1 byte to a   
   > FAT partition at offset 372, you can use fseek and   
   > fputc, rather than fwrite.   
      
   On the face of it I cannot see from that why you would want multiple   
   functions all to be called fwrite.   
      
   >   
   > Why use names other than the C90-provided ones?   
   > What advantage does calling fatWrite() have compared   
   > to calling it fwrite()?   
      
   In what I suggested,   
      
      app --> language library --> OS library --> shim --> OS interface   
      
   fwrite would live in the  part; and somewhere after the  there would be the more-specific things such as fatWrite,   
   extWrite, etc which would perform a write to each type of filesystem.   
      
   >   
   >> AISI "fwrite" is what a program invokes in order to carry out the fwrite   
   >> function. What the fwrite routine does to /implement/ that operation   
   >> should, I would have thought, be immaterial.   
   >   
   > It *is* immaterial. However, why not chuck those immaterial   
   > things like DosWrite(), WriteFile(), fatWrite(), PosWriteFile(),   
   > BosWriteSector() into the C library (as separate #ifdefs)?   
      
   Well,....   
      
   * The C library should, I would have thought, include only the standard   
   functions, whatever they are, so that it would be portable, rather than   
   adding a whole lot of new functions to it. The software world is   
   littered with incompatible supersets.   
      
   * If non-standard IO functions are desirable it would be more modular to   
   place them in their own library and be described by their own header file.   
      
   * If they mean what I think they mean I can't see why you would want a   
   DosWrite, a fatWrite etc. They would appear to restrict IO to certain   
   filesystems whereas the specific operation on a filesystem is usually   
   encoded in a driver for that filesystem type.   
      
   * Re. #ifdefs, conditional compilation is often used as a kludge and   
   makes code more costly to maintain. It's like goto - easy to add but   
   makes code harder to read and update.   
      
      
   --   
   James Harris   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)