From: lew.pitcher@digitalfreehold.ca   
      
   On Tue, 20 Feb 2024 22:25:05 +0800, Paul Edwards wrote:   
      
   > On 20/02/24 22:14, Lew Pitcher wrote:   
   >> On Tue, 20 Feb 2024 14:51:15 +0800, Paul Edwards wrote:   
   >>   
   >>> Hi.   
   >>>   
   >>> Cygwin has an O_TEXT on the open() call to let   
   >>> "the OS layer" (can be quibbled) that the file   
   >>> is being opened in text mode. And as such, it   
   >>> gives that layer an opportunity to insert CRs.   
   >> [snip]   
   >>> I'd like to add an O_TEXT flag to Linux.[snip]   
   >>> Any suggestions?   
   >>   
   >> Yes, one. Dont.   
   >>   
   >> Microsoft Windows (on top of which Cygwin must run) makes a low-level   
   >> distinction between "binary" files and "text" files. I believe it is   
   >> because Windows guarantees (or must guarantee) certain data   
   >> transformations on text that do not apply to other forms of data.   
   >> (I.e. translating  sequences into C newline characters, etc)   
   >>   
   >> HOWEVER, Linux (or, /any/ Unix) makes NO distinction between text   
   >> and binary data, neither in the standard I/O library, nor in the OS   
   >> itself.   
   >>   
   >> You are effectively asking that Linux /NOW/ make such a distinction,   
   >> even if only to ignore the O_TEXT flag that you ask for.   
   >   
   > The C library that most people use already has   
   > that distinction - and it is indeed ignored.   
   > Works perfectly fine.   
      
   Lets take an accounting...   
      
   1) POSIX open() does not make any distinction between "text" and "binary"   
      files   
      
   2) Standard C / POSIX fopen() /does/ make a distinction between "text"   
      and "binary" files. POSIX issues a caveat regarding the mode   
      parameter that "The character 'b' shall have no effect, but is allowed   
      for ISO C standard conformance.", referring to the mode character "b"   
      specified by the ISO C standard as indicating that the file should be   
      opened for "binary" I/O, rather than the default "text" I/O.   
      
   3) You specifically reference the open() call, not the fopen() call.   
      
   So, you ask that the open() call, a call that, under Linux and other   
   POSIX-compatible operating systems, makes no distinction between binary   
   and text files, now recognize a flag indicating that the open() should   
   act apon a text file.   
      
   That leaves the Linux kernel developers with a choice to make: either   
   a) accept your request and add an O_TEXT flag that conditions the I/O   
      for text data, or   
   b) accept your request and add an O_TEXT flag that does nothing, or   
   c) ignore or deny your request   
      
   Choice (a) would drastically change the behaviour of the open()   
   call, and any existing code that uses open() to access a text file would   
   have to change to specify the O_TEXT flag. I believe that this would   
   be a no-starter, even if the default for O_TEXT would leave behaviour   
   as it currently is.   
      
   Choice (b) is ... useless. It recognizes a non-issue, and does nothing.   
   It would be a header change that reserves a flag that would be ignored   
   by everyone. I believe that the maintainers would simply veto this   
   as being a change that makes no change.   
      
   So, choice (c) is my bet. The maintainers simply ignore (if they want   
   to be polite) or deny your proposal.   
      
   >   
   >> It ain't gonna fly. Such a flag would invalidate /decades/ worth of   
   >> Unix/Linux code, and /not/ provide any functionality either to   
   >> the OS layer, the stdio library layer, or the application code layer.   
   >   
   > Sorry - what is being invalidated? Can you give an   
   > example?   
      
   Today, I can   
     open("/etc/passwd",O_RDONLY)   
   and read text from the text file /etc/passwd. I can   
   also   
     open("/sbin/init",O_RDONLY)   
   and read binary data from the binary file /sbin/init   
      
   If I understand correctly, you propose that code now   
   must   
     open("/etc/passwd",O_RDONLY | O_TEXT)   
   to read text from the text file /etc/passwd.   
      
   What would happen if, under your proposal, code still   
   executed   
     open("/etc/passwd",O_RDONLY)   
   ? Could the code still read() text data, or would the   
   open() fail on something like EACCESS or EINVAL or   
   EOPNOTSUPP? What /would/ the consequences be of setting   
   O_TEXT?   
      
   Of course, if you answer that, under a POSIX-like system,   
   there would be /no/ consequences to O_TEXT, then you   
   have presented choice (b), a change that changes nothing.   
      
   --   
   Lew Pitcher   
   "In Skills We Trust"   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)