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

Groups > comp.lang.c > #163699 > unrolled thread

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

Back to article view | Back to comp.lang.c

Contents

  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

Page 2 of 2 — ← Prev page 1 [2]

#163730

On 07/12/2021 01:11, John Forkosh wrote:
> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:

>> Anyway, if the most widely used C library does not support it, it's not
>> portable in any useful way.
> 
> Thanks, Ben and Bonita (and Malcom and Manfred), yeah I also "feared
> this would be the case", i.e., no portable solution like freopen(),
> which would be syntactically identical on all platforms and "just work",
> whether needed (windows) or not (linux).
> 
> By the way, at least at the time when I wrote that stackexchange post,
> some windows C compilers used _setmode(_fileno(stderr),_O_BINARY)
> like Bonita said, but some others used setmode(fileno(stderr),O_BINARY).
> So additional #ifdefs needed to resolve that. And I'm also not sure
> that _MSC_VER always identifies all windows C compilers. The elaborate
> #ifdefs illustrated on that stackexchange post were what I ended up
> with to accommodate all the variations I'd encountered at the time
> I wrote it. So I was hoping to find some less elaborate and fewer
> lines of gobbledy-gook code, if not entirely 100% portable, to identify
> and handle all possible windows situations.
> 

Every Windows system comes with a C library called msvcrt.dll. And 
msvcrt.dll (usually located in C:\windows\system32) defines _setmode.

That means I can reliably call that function even from a script language 
as follows:

     importdll msvcrt=
         clang function _setmode(int32,int32)int32
     end

     println _setmode(1,32768)     # 1=stdout, 32768=O_BINARY

Ironically, this appears difficult to do from C!

First because it's hard to pinpoint that function in that specific 
library. But also because it needs to be the same library that is used 
by your *printf and other functions, otherwise you're setting the mode 
of the wrong library.

You would need, somehow, to specifically link with this library, but 
even then, there might be shortcomings: some parts of it might too slow; 
some other functions could be missing.

(With my script, the call works both for native 'print' which eventually 
calls 'printf' of the C library dynamically linked to the interpreter 
executable, and for direct 'printf' calls within that msvcrt loaded by 
the script (printf declaration and use not shown).

I expected there to be two instances of msvcrt, but presumably the OS 
sees them as both invoked by the same program so they must share data.)

[toc] | [prev] | [next] | [standalone]

#163732

Bart <bc@freeuk.com> wrote:
> John Forkosh wrote:
>> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> 
>>> Anyway, if the most widely used C library does not support it, it's not
>>> portable in any useful way.
>> 
>> Thanks, Ben and Bonita (and Malcom and Manfred), yeah I also "feared
>> this would be the case", i.e., no portable solution like freopen(),
>> which would be syntactically identical on all platforms and "just work",
>> whether needed (windows) or not (linux).
>> 
>> By the way, at least at the time when I wrote that stackexchange post,
>> some windows C compilers used _setmode(_fileno(stderr),_O_BINARY)
>> like Bonita said, but some others used setmode(fileno(stderr),O_BINARY).
>> So additional #ifdefs needed to resolve that. And I'm also not sure
>> that _MSC_VER always identifies all windows C compilers. The elaborate
>> #ifdefs illustrated on that stackexchange post were what I ended up
>> with to accommodate all the variations I'd encountered at the time
>> I wrote it. So I was hoping to find some less elaborate and fewer
>> lines of gobbledy-gook code, if not entirely 100% portable, to identify
>> and handle all possible windows situations.
>> 
> 
> Every Windows system comes with a C library called msvcrt.dll. And 
> msvcrt.dll (usually located in C:\windows\system32) defines _setmode.
> 
> That means I can reliably call that function even from a script language 
> as follows:
> 
>     importdll msvcrt=
>         clang function _setmode(int32,int32)int32
>     end
> 
>     println _setmode(1,32768)     # 1=stdout, 32768=O_BINARY
> 
> Ironically, this appears difficult to do from C!
> 
> First because it's hard to pinpoint that function in that specific 
> library. But also because it needs to be the same library that is used 
> by your *printf and other functions, otherwise you're setting the mode 
> of the wrong library.
> 
> You would need, somehow, to specifically link with this library, but 
> even then, there might be shortcomings: some parts of it might too slow; 
> some other functions could be missing.
> 
> (With my script, the call works both for native 'print' which eventually 
> calls 'printf' of the C library dynamically linked to the interpreter 
> executable, and for direct 'printf' calls within that msvcrt loaded by 
> the script (printf declaration and use not shown).
> 
> I expected there to be two instances of msvcrt, but presumably the OS 
> sees them as both invoked by the same program so they must share data.)

Thanks, Bart. I'll try that approach next time I take a look at
that code, though probably not soon (I only posted the followup
question since the op was already barking up the very same tree).
In any case, seems like there's no way around an overly-elaborate
solution to what should be a completely trivial task (i.e., the
one-line freopen() ought to "just work"). So if/when I do take
another look, I'll almost-certainly encapsulate the inevitable
gobbledy-gook #ifdefs/code/whatever into its own little function,
so it doesn't interrupt main()'s more straightforward logical flow.
-- 
John Forkosh  ( mailto:  j@f.com  where j=john and f=forkosh )

[toc] | [prev] | [next] | [standalone]

#163757

Meredith Montgomery <mmontgomery@levado.to> writes:

> I know this isn't C.  I'm not aware of any group like
> comp.windows.programmer.  [...]

I suggest you try stackoverflow.

[toc] | [prev] | [next] | [standalone]

#163764

In article <867dcc966s.fsf@linuxsc.com>,
Tim Rentsch  <tr.17687@z991.linuxsc.com> wrote:
>Meredith Montgomery <mmontgomery@levado.to> writes:
>
>> I know this isn't C.  I'm not aware of any group like
>> comp.windows.programmer.  [...]
>
>I suggest you try stackoverflow.

Or get a better newsserver...

$ grep windows.progr GROUPS.news
comp.os.ms-windows.programmer.controls 0000037091 0000037092 y
comp.os.ms-windows.programmer.graphics 0000040642 0000040643 y
comp.os.ms-windows.programmer.memory 0000013480 0000013481 y
comp.os.ms-windows.programmer.misc 0000008003 0000008001 y
comp.os.ms-windows.programmer.multimedia 0000027043 0000027044 y
comp.os.ms-windows.programmer.networks 0000022813 0000022814 y
comp.os.ms-windows.programmer.nt.kernel-mode 0000077071 0000077071 y
comp.os.ms-windows.programmer.ole 0000023431 0000023432 y
comp.os.ms-windows.programmer.tools.mfc 0000110469 0000110470 y
comp.os.ms-windows.programmer.tools.misc 0000017120 0000017121 y
comp.os.ms-windows.programmer.tools.owl 0000023129 0000023130 y
comp.os.ms-windows.programmer.tools.winsock 0000019735 0000019736 y
comp.os.ms-windows.programmer.vxd 0000034719 0000034720 y
comp.os.ms-windows.programmer.win32 0000282373 0000282105 y
comp.os.ms-windows.programmer.winhelp 0000028693 0000028694 y
de.comp.os.ms-windows.programmer 0000041069 0000041068 y
es.comp.os.ms-windows.programacion 0000011998 0000011999 y
fj.os.ms-windows.programming 0000013012 0000013013 y
fr.comp.os.ms-windows.programmation 0000072256 0000072234 y
$ 

Note that the file mentioned above is a file that I maintain on my system
so I can lookup things like this.  It is created by a script that telnets
into my newsserver and then records the results.

-- 
Just like Donald Trump today, Jesus Christ had a Messiah complex.

And, in fact, the similarities between the two figures are quite striking.
For example, both have a ragtag band of followers, whose faith cannot be shaken.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.c

csiph-web