Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.c > #163704

Re: ot: on stdin, stdout, stderr and crlf on windows

From Mike Terry <news.dead.person.stones@darjeeling.plus.com>
Newsgroups comp.lang.c
Subject Re: ot: on stdin, stdout, stderr and crlf on windows
Date 2021-12-05 03:33 +0000
Organization Aioe.org NNTP Server
Message-ID <sohbtp$s2p$1@gioia.aioe.org> (permalink)
References <86fsr8uf6a.fsf@levado.to> <-56dnQtxBsW3mTH8nZ2dnUU78RnNnZ2d@brightview.co.uk> <86zgpfsszj.fsf@levado.to>

Show all headers | View raw


On 05/12/2021 02:09, Meredith Montgomery wrote:
> Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
> 
>> On 04/12/2021 23:24, Meredith Montgomery wrote:
>>> I know this isn't C.  I'm not aware of any group like
>>> comp.windows.programmer.  If there is one, I'd appreciate if you set the
>>> follow-up-to header.  Thank you.
>>> Windows provides me _setmode(), with which I can put stdout on
>>> _O_BINARY.  It then stops replacing \n with \r\n.  However, it seems
>>> that Windows does not do any such replacements on stdin and stderr.
> 
> Sorry.  It does happen on stderr.  (And now I understand what I missed
> about stdin.  See below.)  And thank you, Mike Terry.
> 
>>> I looked for a confirmation of this apparent fact and could not find
>>> it.  Can you advise?  I don't see the replacements taking place; only
>>> on stdout it seems to happen.  I'm not sure how to prove that.
>>> Here's my attempt.  This program below shows all bytes it reads from
>>> stdin.  C:\tmp>cat show-c.c #include <stdio.h> int main() { int c;
>>> while ( (c = getchar()) != EOF) { printf("%d", c); } printf("\n"); }
>>> C:\tmp>show-c.exe < empty.txt 10 So empty.txt must contain at least
>>> byte 10.  But if Windows were fixing my line-terminations, it should
>>> have added a byte 13 (on my back).
>>
>> This is backwards - by default Windows (well, VC++ compiler at least)
>> assumes text lines end CR LF  (decimal values 13, 10).  The default
>> text mode will convert CR LF to just LF, which you are seeing above -
>> presumably empty.txt has just a single empty line terminated by CR LF
>> ??   If you set the stdin mode to binary you should then expect output
>> "1310".
> 
> You're right.  The Windows situation is reversed when we deal with
> stdin.  If I input \r\n, it replaces to \n if in _O_TEXT.  I totally
> missed that indeed because --- well, it's so confusing.  Thank you.
> 
> By the way, because I used write() and saw the translations taking
> place, I conclude the kernel is doing these translations, not the local
> C library.

On Windows the low level OS APIs for file IO are ReadFile[Ex] and 
WriteFile[Ex].  These do not know about line endings, or whether the 
files are ANSI/Unicode etc., they just read/write a block of data. 
Functions like read() write() are part of the CRT, and will internally 
end up calling ReadFile/WriteFile or one of their variants.

Regards,
Mike.




















> 

Back to comp.lang.c | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

ot: on stdin, stdout, stderr and crlf on windows Meredith Montgomery <mmontgomery@levado.to> - 2021-12-04 20:24 -0300
  Re: ot: on stdin, stdout, stderr and crlf on windows Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2021-12-05 00:01 +0000
  Re: ot: on stdin, stdout, stderr and crlf on windows Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2021-12-05 00:13 +0000
    Re: ot: on stdin, stdout, stderr and crlf on windows Meredith Montgomery <mmontgomery@levado.to> - 2021-12-04 23:09 -0300
      Re: ot: on stdin, stdout, stderr and crlf on windows Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-12-04 18:27 -0800
      Re: ot: on stdin, stdout, stderr and crlf on windows Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2021-12-05 03:33 +0000
        Re: ot: on stdin, stdout, stderr and crlf on windows Meredith Montgomery <mmontgomery@levado.to> - 2021-12-05 09:17 -0300
  Re: ot: on stdin, stdout, stderr and crlf on windows Bonita Montero <Bonita.Montero@gmail.com> - 2021-12-05 15:04 +0100
  Re: ot: on stdin, stdout, stderr and crlf on windows Bonita Montero <Bonita.Montero@gmail.com> - 2021-12-05 15:13 +0100
    Re: ot: on stdin, stdout, stderr and crlf on windows John Forkosh <forkosh@panix.com> - 2021-12-06 08:20 +0000
      Re: ot: on stdin, stdout, stderr and crlf on windows Bonita Montero <Bonita.Montero@gmail.com> - 2021-12-06 09:45 +0100
      Re: ot: on stdin, stdout, stderr and crlf on windows Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-12-06 10:36 +0000
        Re: ot: on stdin, stdout, stderr and crlf on windows Bonita Montero <Bonita.Montero@gmail.com> - 2021-12-06 13:03 +0100
          Re: ot: on stdin, stdout, stderr and crlf on windows Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-12-06 12:34 +0000
            Re: ot: on stdin, stdout, stderr and crlf on windows Manfred <noname@add.invalid> - 2021-12-06 14:38 +0100
              Re: ot: on stdin, stdout, stderr and crlf on windows Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-12-06 06:00 -0800
                Re: ot: on stdin, stdout, stderr and crlf on windows Manfred <noname@add.invalid> - 2021-12-06 18:59 +0100
              Re: ot: on stdin, stdout, stderr and crlf on windows Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-12-06 17:08 +0000
                Re: ot: on stdin, stdout, stderr and crlf on windows scott@slp53.sl.home (Scott Lurndal) - 2021-12-06 17:18 +0000
            Re: ot: on stdin, stdout, stderr and crlf on windows John Forkosh <forkosh@panix.com> - 2021-12-07 01:11 +0000
              Re: ot: on stdin, stdout, stderr and crlf on windows Bart <bc@freeuk.com> - 2021-12-07 09:56 +0000
                Re: ot: on stdin, stdout, stderr and crlf on windows John Forkosh <forkosh@panix.com> - 2021-12-08 08:13 +0000
  Re: ot: on stdin, stdout, stderr and crlf on windows Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-12-10 01:10 -0800
    Re: ot: on stdin, stdout, stderr and crlf on windows gazelle@shell.xmission.com (Kenny McCormack) - 2021-12-10 11:00 +0000

csiph-web