Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #163704
| 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> |
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 | Next — Previous in thread | Next in thread | Find similar | Unroll 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