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 1 of 2  [1] 2  Next page →

#163699 — ot: on stdin, stdout, stderr and crlf on windows

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.  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).

Perhaps I just proved that Windows is not replacing anything on my
stdin.  

(*) Not sure of the relevance of this

C:\tmp>file show-c
show-c: PE32+ executable (console) x86-64, for MS Windows

Thank you so much.

[toc] | [next] | [standalone]

#163700

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.  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.

Not sure of the proper group.  Anyway, have you read the _setmode() 
documentation?

 
<https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/setmode>

That page contains a code example to change stdin to binary - exactly 
what you're after.

> 
> 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");
> }

Um, there's no call to _setmode() in your code. :)

Mike.

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

#163701

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.  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".

Mike.

> 
> Perhaps I just proved that Windows is not replacing anything on my
> stdin.
> 
> (*) Not sure of the relevance of this
> 
> C:\tmp>file show-c
> show-c: PE32+ executable (console) x86-64, for MS Windows
> 
> Thank you so much.
> 

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

#163702

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.

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

#163703

Meredith Montgomery <mmontgomery@levado.to> writes:
[...]
> 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.

It's not too confusing once you understand it.

On UNIX, C's original home, text files use LF (ASCII 0x0a), and only
LF, to mark the end of a line in a text file.  So you can read raw
data from a text file and assume that an LF character always marks
the end of a line, and write raw data to a text file and be sure
that each LF written will mark the end of a line.

Other systems use different conventions.  MS-DOS and Windows use
a CR-LF pair, and other systems use other character combinations
or more complicated schemes.  C's <stdio.h> is designed to map all
those variations to a single scheme of using '\n'.  So on input,
the OS's end-of-line marker, whatever it is, is tranlated to '\n',
and on output '\n' is translated to the OS's end-of-line marker.

stdin, stdout, and stderr are all text streams, so operations on them
all perform this mapping, one way or the other.

> 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.

I wouldn't assume that.  On Linux/Unix systems, write is usually a
system call implemented by the kernel.  (POSIX just says it's a
function, but it happens to be implemented as a system call on most
Unix-like systems).  On Windows, the write() function is probably
implemented on top of lower-level Windows calls.  On systems where
write() is a system call, it doesn't transform end-of-line markers
because it doesn't need to.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

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

#163704

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.




















> 

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

#163705

Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:

[...]

>>>> 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.

Interesting info.  Thanks so much.

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

#163706

Eh,
	_setmode( _fileno( stdin ), _O_BINARY );
/
	_setmode( _fileno( stderr ), _O_BINARY );

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

#163707

Am 05.12.2021 um 00:24 schrieb Meredith Montgomery:
> 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.  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).
> 
> Perhaps I just proved that Windows is not replacing anything on my
> stdin.
> 
> (*) Not sure of the relevance of this
> 
> C:\tmp>file show-c
> show-c: PE32+ executable (console) x86-64, for MS Windows
> 
> Thank you so much.

Check the output of this in your hex-editor:

#include <stdio.h>
#include <fcntl.h>
#include <io.h>
#include <stdlib.h>

int main( int argc, char **argv )
{
	if( argc >= 2 && _setmode( _fileno( stderr ), _O_BINARY ) == -1 )
		return EXIT_FAILURE;
	fprintf( stderr, "it works !\n" );
}

Without a commandline-parameter you've 0x0D, 0x0A
as a line-separator, with you've got only 0x0A.

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

#163710

Bonita Montero <Bonita.Montero@gmail.com> wrote:
> Meredith Montgomery wrote:
>> 
>> 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.  I
>> looked for a confirmation of this apparent fact and could not find it.
 <<snip>>
> 
> Check the output of this in your hex-editor:
> 
> #include <stdio.h>
> #include <fcntl.h>
> #include <io.h>
> #include <stdlib.h>
> 
> int main( int argc, char **argv )
> {
>        if( argc >= 2 && _setmode( _fileno( stderr ), _O_BINARY ) == -1 )
>                return EXIT_FAILURE;
>        fprintf( stderr, "it works !\n" );
> }
> 
> Without a commandline-parameter you've 0x0D, 0x0A
> as a line-separator, with you've got only 0x0A.

Yeah, that's more or less what I've been doing, but is there
maybe a portable way to do it, i.e., for programs intended to
run both under windows and linux? I asked that on stackexchange
some five years ago,
     https://stackoverflow.com/questions/40609260/
but still no solution.
-- 
John Forkosh  ( mailto:  j@f.com  where j=john and f=forkosh )

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

#163711

Am 06.12.2021 um 09:20 schrieb John Forkosh:
> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>> Meredith Montgomery wrote:
>>>
>>> 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.  I
>>> looked for a confirmation of this apparent fact and could not find it.
>   <<snip>>
>>
>> Check the output of this in your hex-editor:
>>
>> #include <stdio.h>
>> #include <fcntl.h>
>> #include <io.h>
>> #include <stdlib.h>
>>
>> int main( int argc, char **argv )
>> {
>>         if( argc >= 2 && _setmode( _fileno( stderr ), _O_BINARY ) == -1 )
>>                 return EXIT_FAILURE;
>>         fprintf( stderr, "it works !\n" );
>> }
>>
>> Without a commandline-parameter you've 0x0D, 0x0A
>> as a line-separator, with you've got only 0x0A.
> 
> Yeah, that's more or less what I've been doing, but is there
> maybe a portable way to do it, i.e., for programs intended to
> run both under windows and linux? 


#include <stdio.h>
#if define(_MSC_VER)
     #include <fcntl.h>
     #include <io.h>
     #include <stdlib.h>
#endif

int main( int argc, char **argv )
{
#if define(_MSC_VER)
     if( argc >= 2 && _setmode( _fileno( stderr ), _O_BINARY ) == -1 )
         return EXIT_FAILURE;
#endif
     fprintf( stderr, "it works !\n" );
}

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

#163713

John Forkosh <forkosh@panix.com> writes:

> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>> Meredith Montgomery wrote:
>>> 
>>> 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.  I
>>> looked for a confirmation of this apparent fact and could not find it.
>  <<snip>>
>> 
>> Check the output of this in your hex-editor:
>> 
>> #include <stdio.h>
>> #include <fcntl.h>
>> #include <io.h>
>> #include <stdlib.h>
>> 
>> int main( int argc, char **argv )
>> {
>>        if( argc >= 2 && _setmode( _fileno( stderr ), _O_BINARY ) == -1 )
>>                return EXIT_FAILURE;
>>        fprintf( stderr, "it works !\n" );
>> }
>> 
>> Without a commandline-parameter you've 0x0D, 0x0A
>> as a line-separator, with you've got only 0x0A.

Summary: making stdout binary.

> Yeah, that's more or less what I've been doing, but is there
> maybe a portable way to do it, i.e., for programs intended to
> run both under windows and linux?

There's a standard function that /could/ do it, but it is allowed to be
no-op.  I don't have access to a Windows programming environment, so I
can't check it:

  freopen(NULL, "ab", stdout);

(or maybe "wb", it's the b you want of course).

-- 
Ben.

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

#163716

Am 06.12.2021 um 11:36 schrieb Ben Bacarisse:
 > John Forkosh <forkosh@panix.com> writes:
 >
 >> Bonita Montero <Bonita.Montero@gmail.com> wrote:
 >>> Meredith Montgomery wrote:
 >>>>
 >>>> 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.  I
 >>>> looked for a confirmation of this apparent fact and could not find it.
 >>   <<snip>>
 >>>
 >>> Check the output of this in your hex-editor:
 >>>
 >>> #include <stdio.h>
 >>> #include <fcntl.h>
 >>> #include <io.h>
 >>> #include <stdlib.h>
 >>>
 >>> int main( int argc, char **argv )
 >>> {
 >>>         if( argc >= 2 && _setmode( _fileno( stderr ), _O_BINARY ) 
== -1 )
 >>>                 return EXIT_FAILURE;
 >>>         fprintf( stderr, "it works !\n" );
 >>> }
 >>>
 >>> Without a commandline-parameter you've 0x0D, 0x0A
 >>> as a line-separator, with you've got only 0x0A.
 >
 > Summary: making stdout binary.
 >
 >> Yeah, that's more or less what I've been doing, but is there
 >> maybe a portable way to do it, i.e., for programs intended to
 >> run both under windows and linux?
 >
 > There's a standard function that /could/ do it, but it is allowed to be
 > no-op.  I don't have access to a Windows programming environment, so I
 > can't check it:
 >
 >    freopen(NULL, "ab", stdout);
 >
 > (or maybe "wb", it's the b you want of course).
Doesn't work with either wb or ab:

#include <stdio.h>
#include <stdlib.h>

int main( int argc, char **argv )
{
	if( argc < 2 )
		return EXIT_FAILURE;
	FILE *pfErr = freopen( NULL, argv[1], stderr);
	printf( "%p", (void *)pfErr );
}

  en.cppreference.com says:

"Microsoft CRT version of std::freopen does not support any mode
  changes when filename is a null pointer and treats this as an
  error (see documentation). A possible workaround is the non
  -standard function _setmode()."

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

#163717

Bonita Montero <Bonita.Montero@gmail.com> writes:

> Am 06.12.2021 um 11:36 schrieb Ben Bacarisse:
>> John Forkosh <forkosh@panix.com> writes:
>>
>>> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>>> Meredith Montgomery wrote:
>>>>>
>>>>> 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.  I
>>>>> looked for a confirmation of this apparent fact and could not find it.
>>>   <<snip>>
>>>>
>>>> Check the output of this in your hex-editor:
>>>>
>>>> #include <stdio.h>
>>>> #include <fcntl.h>
>>>> #include <io.h>
>>>> #include <stdlib.h>
>>>>
>>>> int main( int argc, char **argv )
>>>> {
>>>>         if( argc >= 2 && _setmode( _fileno( stderr ), _O_BINARY ) == -1 )
>>>>                 return EXIT_FAILURE;
>>>>         fprintf( stderr, "it works !\n" );
>>>> }
>>>>
>>>> Without a commandline-parameter you've 0x0D, 0x0A
>>>> as a line-separator, with you've got only 0x0A.
>>
>> Summary: making stdout binary.
>>
>>> Yeah, that's more or less what I've been doing, but is there
>>> maybe a portable way to do it, i.e., for programs intended to
>>> run both under windows and linux?
>>
>> There's a standard function that /could/ do it, but it is allowed to be
>> no-op.  I don't have access to a Windows programming environment, so I
>> can't check it:
>>
>>    freopen(NULL, "ab", stdout);
>>
>> (or maybe "wb", it's the b you want of course).
> Doesn't work with either wb or ab:
>
> #include <stdio.h>
> #include <stdlib.h>
>
> int main( int argc, char **argv )
> {
> 	if( argc < 2 )
> 		return EXIT_FAILURE;
> 	FILE *pfErr = freopen( NULL, argv[1], stderr);
> 	printf( "%p", (void *)pfErr );
> }
>
>  en.cppreference.com says:
>
> "Microsoft CRT version of std::freopen does not support any mode
>  changes when filename is a null pointer and treats this as an
>  error (see documentation). A possible workaround is the non
>  -standard function _setmode()."

I feared this would be the case.  It was many years ago when this last
came up.  Maybe some alternative C library has made what appears to be
the trivial modification to make it work?

Anyway, if the most widely used C library does not support it, it's not
portable in any useful way.

-- 
Ben.

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

#163718

On 12/6/2021 1:34 PM, Ben Bacarisse wrote:
> Bonita Montero <Bonita.Montero@gmail.com> writes:
> 
>> Am 06.12.2021 um 11:36 schrieb Ben Bacarisse:
>>> John Forkosh <forkosh@panix.com> writes:
>>>
>>>> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>>>> Meredith Montgomery wrote:
>>>>>>
>>>>>> 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.  I
>>>>>> looked for a confirmation of this apparent fact and could not find it.
>>>>    <<snip>>
>>>>>
>>>>> Check the output of this in your hex-editor:
>>>>>
>>>>> #include <stdio.h>
>>>>> #include <fcntl.h>
>>>>> #include <io.h>
>>>>> #include <stdlib.h>
>>>>>
>>>>> int main( int argc, char **argv )
>>>>> {
>>>>>          if( argc >= 2 && _setmode( _fileno( stderr ), _O_BINARY ) == -1 )
>>>>>                  return EXIT_FAILURE;
>>>>>          fprintf( stderr, "it works !\n" );
>>>>> }
>>>>>
>>>>> Without a commandline-parameter you've 0x0D, 0x0A
>>>>> as a line-separator, with you've got only 0x0A.
>>>
>>> Summary: making stdout binary.
>>>
>>>> Yeah, that's more or less what I've been doing, but is there
>>>> maybe a portable way to do it, i.e., for programs intended to
>>>> run both under windows and linux?
>>>
>>> There's a standard function that /could/ do it, but it is allowed to be
>>> no-op.  I don't have access to a Windows programming environment, so I
>>> can't check it:
>>>
>>>     freopen(NULL, "ab", stdout);
>>>
>>> (or maybe "wb", it's the b you want of course).
>> Doesn't work with either wb or ab:
>>
>> #include <stdio.h>
>> #include <stdlib.h>
>>
>> int main( int argc, char **argv )
>> {
>> 	if( argc < 2 )
>> 		return EXIT_FAILURE;
>> 	FILE *pfErr = freopen( NULL, argv[1], stderr);
>> 	printf( "%p", (void *)pfErr );
>> }
>>
>>   en.cppreference.com says:
>>
>> "Microsoft CRT version of std::freopen does not support any mode
>>   changes when filename is a null pointer and treats this as an
>>   error (see documentation). A possible workaround is the non
>>   -standard function _setmode()."
> 
> I feared this would be the case.  It was many years ago when this last
> came up.  Maybe some alternative C library has made what appears to be
> the trivial modification to make it work?
> 
> Anyway, if the most widely used C library does not support it, it's not
> portable in any useful way.
> 

I'm not sure the Microsoft CRT is the most widely used library (I'd say 
it is on Windows, in general I think it isn't), but it's used widely 
enough to make portability an issue, sure.

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

#163719

On Monday, 6 December 2021 at 13:38:21 UTC, Manfred wrote:
> On 12/6/2021 1:34 PM, Ben Bacarisse wrote: 
> > Bonita Montero <Bonita....@gmail.com> writes: 
> > 
> >> Am 06.12.2021 um 11:36 schrieb Ben Bacarisse: 
> >>> John Forkosh <for...@panix.com> writes: 
> >>> 
> >>>> Bonita Montero <Bonita....@gmail.com> wrote: 
> >>>>> Meredith Montgomery wrote: 
> >>>>>> 
> >>>>>> 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. I 
> >>>>>> looked for a confirmation of this apparent fact and could not find it. 
> >>>> <<snip>> 
> >>>>> 
> >>>>> Check the output of this in your hex-editor: 
> >>>>> 
> >>>>> #include <stdio.h> 
> >>>>> #include <fcntl.h> 
> >>>>> #include <io.h> 
> >>>>> #include <stdlib.h> 
> >>>>> 
> >>>>> int main( int argc, char **argv ) 
> >>>>> { 
> >>>>> if( argc >= 2 && _setmode( _fileno( stderr ), _O_BINARY ) == -1 ) 
> >>>>> return EXIT_FAILURE; 
> >>>>> fprintf( stderr, "it works !\n" ); 
> >>>>> } 
> >>>>> 
> >>>>> Without a commandline-parameter you've 0x0D, 0x0A 
> >>>>> as a line-separator, with you've got only 0x0A. 
> >>> 
> >>> Summary: making stdout binary. 
> >>> 
> >>>> Yeah, that's more or less what I've been doing, but is there 
> >>>> maybe a portable way to do it, i.e., for programs intended to 
> >>>> run both under windows and linux? 
> >>> 
> >>> There's a standard function that /could/ do it, but it is allowed to be 
> >>> no-op. I don't have access to a Windows programming environment, so I 
> >>> can't check it: 
> >>> 
> >>> freopen(NULL, "ab", stdout); 
> >>> 
> >>> (or maybe "wb", it's the b you want of course). 
> >> Doesn't work with either wb or ab: 
> >> 
> >> #include <stdio.h> 
> >> #include <stdlib.h> 
> >> 
> >> int main( int argc, char **argv ) 
> >> { 
> >> if( argc < 2 ) 
> >> return EXIT_FAILURE; 
> >> FILE *pfErr = freopen( NULL, argv[1], stderr); 
> >> printf( "%p", (void *)pfErr ); 
> >> } 
> >> 
> >> en.cppreference.com says: 
> >> 
> >> "Microsoft CRT version of std::freopen does not support any mode 
> >> changes when filename is a null pointer and treats this as an 
> >> error (see documentation). A possible workaround is the non 
> >> -standard function _setmode()." 
> > 
> > I feared this would be the case. It was many years ago when this last 
> > came up. Maybe some alternative C library has made what appears to be 
> > the trivial modification to make it work? 
> > 
> > Anyway, if the most widely used C library does not support it, it's not 
> > portable in any useful way. 
> >
> I'm not sure the Microsoft CRT is the most widely used library (I'd say 
> it is on Windows, in general I think it isn't), but it's used widely 
> enough to make portability an issue, sure.
>
The days when everyone used Windows except for a few types who worked in
universities or big research companies and had Unix are gone. I'm typing
this on an Apple. 

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

#163723

On 12/6/2021 3:00 PM, Malcolm McLean wrote:
> On Monday, 6 December 2021 at 13:38:21 UTC, Manfred wrote:
>> On 12/6/2021 1:34 PM, Ben Bacarisse wrote:
>>> Bonita Montero <Bonita....@gmail.com> writes:
[...]
>>>> en.cppreference.com says:
>>>>
>>>> "Microsoft CRT version of std::freopen does not support any mode
>>>> changes when filename is a null pointer and treats this as an
>>>> error (see documentation). A possible workaround is the non
>>>> -standard function _setmode()."
>>>
>>> I feared this would be the case. It was many years ago when this last
>>> came up. Maybe some alternative C library has made what appears to be
>>> the trivial modification to make it work?
>>>
>>> Anyway, if the most widely used C library does not support it, it's not
>>> portable in any useful way.
>>>
>> I'm not sure the Microsoft CRT is the most widely used library (I'd say
>> it is on Windows, in general I think it isn't), but it's used widely
>> enough to make portability an issue, sure.
>>
> The days when everyone used Windows except for a few types who worked in
> universities or big research companies and had Unix are gone. I'm typing
> this on an Apple.
> 

There is also the fact about how much the CRT library is actually used 
on Windows.
Yes, it is used, but Microsoft puts very little effort on C, more on 
C++, and both languages get much less attention from them than other 
frameworks, like the Windows API or .NET nowadays.
In other words, I believe there's a lot of Windows apps being developed 
that do not use the CRT, at least as of recent.
On the other hand, virtually all of *nix code relies on (g)libc, and the 
same is probably true for the embedded world (I have no idea about iOS)

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

#163721

Manfred <noname@add.invalid> writes:

> On 12/6/2021 1:34 PM, Ben Bacarisse wrote:
>> Bonita Montero <Bonita.Montero@gmail.com> writes:
>> 
>>> Am 06.12.2021 um 11:36 schrieb Ben Bacarisse:
>>>> John Forkosh <forkosh@panix.com> writes:
>>>>
>>>>> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>>>>> Meredith Montgomery wrote:
>>>>>>>
>>>>>>> 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.  I
>>>>>>> looked for a confirmation of this apparent fact and could not find it.
>>>>>    <<snip>>
>>>>>>
>>>>>> Check the output of this in your hex-editor:
>>>>>>
>>>>>> #include <stdio.h>
>>>>>> #include <fcntl.h>
>>>>>> #include <io.h>
>>>>>> #include <stdlib.h>
>>>>>>
>>>>>> int main( int argc, char **argv )
>>>>>> {
>>>>>>          if( argc >= 2 && _setmode( _fileno( stderr ), _O_BINARY ) == -1 )
>>>>>>                  return EXIT_FAILURE;
>>>>>>          fprintf( stderr, "it works !\n" );
>>>>>> }
>>>>>>
>>>>>> Without a commandline-parameter you've 0x0D, 0x0A
>>>>>> as a line-separator, with you've got only 0x0A.
>>>>
>>>> Summary: making stdout binary.
>>>>
>>>>> Yeah, that's more or less what I've been doing, but is there
>>>>> maybe a portable way to do it, i.e., for programs intended to
>>>>> run both under windows and linux?
>>>>
>>>> There's a standard function that /could/ do it, but it is allowed to be
>>>> no-op.  I don't have access to a Windows programming environment, so I
>>>> can't check it:
>>>>
>>>>     freopen(NULL, "ab", stdout);
>>>>
>>>> (or maybe "wb", it's the b you want of course).
>>> Doesn't work with either wb or ab:
>>>
>>> #include <stdio.h>
>>> #include <stdlib.h>
>>>
>>> int main( int argc, char **argv )
>>> {
>>> 	if( argc < 2 )
>>> 		return EXIT_FAILURE;
>>> 	FILE *pfErr = freopen( NULL, argv[1], stderr);
>>> 	printf( "%p", (void *)pfErr );
>>> }
>>>
>>>   en.cppreference.com says:
>>>
>>> "Microsoft CRT version of std::freopen does not support any mode
>>>   changes when filename is a null pointer and treats this as an
>>>   error (see documentation). A possible workaround is the non
>>>   -standard function _setmode()."
>> I feared this would be the case.  It was many years ago when this last
>> came up.  Maybe some alternative C library has made what appears to be
>> the trivial modification to make it work?
>> Anyway, if the most widely used C library does not support it, it's not
>> portable in any useful way.
>
> I'm not sure the Microsoft CRT is the most widely used library (I'd
> say it is on Windows, in general I think it isn't), but it's used
> widely enough to make portability an issue, sure.

I meant "on Windows".  On, say, Linux, I would think it does not matter
if freopen(NULL, "wb", stdout) fails, since streams are already binary.

-- 
Ben.

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

#163722

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>Manfred <noname@add.invalid> writes:

>> I'm not sure the Microsoft CRT is the most widely used library (I'd
>> say it is on Windows, in general I think it isn't), but it's used
>> widely enough to make portability an issue, sure.
>
>I meant "on Windows".  On, say, Linux, I would think it does not matter
>if freopen(NULL, "wb", stdout) fails, since streams are already binary.
>

On Unix and POSIX systems:

   "The character 'b' shall have no effect, but is allowed for ISO C standard conformance"

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

#163729

Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> Bonita Montero <Bonita.Montero@gmail.com> writes:
> 
>> Am 06.12.2021 um 11:36 schrieb Ben Bacarisse:
>>> John Forkosh <forkosh@panix.com> writes:
>>>
>>>> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>>>> Meredith Montgomery wrote:
>>>>>>
>>>>>> 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.  I
>>>>>> looked for a confirmation of this apparent fact and could not find it.
>>>>   <<snip>>
>>>>>
>>>>> Check the output of this in your hex-editor:
>>>>>
>>>>> #include <stdio.h>
>>>>> #include <fcntl.h>
>>>>> #include <io.h>
>>>>> #include <stdlib.h>
>>>>>
>>>>> int main( int argc, char **argv )
>>>>> {
>>>>>    if( argc >= 2 && _setmode( _fileno( stderr ), _O_BINARY ) == -1 )
>>>>>            return EXIT_FAILURE;
>>>>>    fprintf( stderr, "it works !\n" );
>>>>> }
>>>>>
>>>>> Without a commandline-parameter you've 0x0D, 0x0A
>>>>> as a line-separator, with you've got only 0x0A.
>>>
>>> Summary: making stdout binary.
>>>
>>>> Yeah, that's more or less what I've been doing, but is there
>>>> maybe a portable way to do it, i.e., for programs intended to
>>>> run both under windows and linux?
>>>
>>> There's a standard function that /could/ do it, but it is allowed to be
>>> no-op.  I don't have access to a Windows programming environment, so I
>>> can't check it:
>>>
>>>    freopen(NULL, "ab", stdout);
>>>
>>> (or maybe "wb", it's the b you want of course).
>> Doesn't work with either wb or ab:
>>
>> #include <stdio.h>
>> #include <stdlib.h>
>>
>> int main( int argc, char **argv )
>> {
>>       if( argc < 2 )
>>               return EXIT_FAILURE;
>>       FILE *pfErr = freopen( NULL, argv[1], stderr);
>>       printf( "%p", (void *)pfErr );
>> }
>>
>>  en.cppreference.com says:
>>
>> "Microsoft CRT version of std::freopen does not support any mode
>>  changes when filename is a null pointer and treats this as an
>>  error (see documentation). A possible workaround is the non
>>  -standard function _setmode()."
> 
> I feared this would be the case.  It was many years ago when this last
> came up.  Maybe some alternative C library has made what appears to be
> the trivial modification to make it work?
> 
> 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.
-- 
John Forkosh  ( mailto:  j@f.com  where j=john and f=forkosh )

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web