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.

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.

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

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.

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 */

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.

>

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.

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

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.

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 )

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

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.

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

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.

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.

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.

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.

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"

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)

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 )

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

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 )

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.

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.