From: phaywood@alphalink.com.au   
      
   Groovy hepcat Lew Pitcher was jivin' in alt.os.linux on Wed, 21 Feb 2024   
   04:55 am. It's a cool scene! Dig it.   
      
   > 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:   
   >>>   
   >>>> 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.   
      
     [Snip.]   
      
   >> 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.   
      
     This would be useless, true. But it would be harmless. It could be   
   defined simply as   
      
   #define O_TEXT 0   
      
   which would mean a mode argument of, say, O_RDONLY | O_TEXT would   
   ammount to O_RDONLY | 0, which would in turn ammount to simply   
   O_RDONLY.   
     I can't see the kernel devs going for it, though.   
      
   > 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?   
      
     I think what the OP is proposing is option (b) above: allow an O_TEXT   
   identifier having no effect.   
      
   > 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.   
      
     Right. This is trivially doable. But, as I said, I can't see this   
   happening.   
     To the OP: a solution to your problem is simple. Put the following   
   lines in your source code before any use of O_TEXT:   
      
   #ifndef O_TEXT   
   #define O_TEXT 0   
   #endif   
      
   --   
      
      
   ----- Dig the NEW and IMPROVED news sig!! -----   
      
      
   -------------- Shaggy was here! ---------------   
                 Ain't I'm a dawg!!   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)