On Mon, 29 Jan 2024 19:33:26 +0100, Janis Papanagnou wrote:

> printf ("%s\n", "My\0string");
>
> which won't work as some may expect (you will only see "My").

I’ve often thought, now that we can assume that strings are normally
UTF-8-encoded, that we can use an alternative UTF-8-derived representation
of NUL that *isn’t* interpreted as a string terminator. E.g.

\xc0\x80

On Mon, 29 Jan 2024 18:47:46 +0000, Malcolm McLean wrote:

> ... I don't think
> my use of standard output is all that untypical. It's unacceptable for
> anything released to customers and is used mainly for debugging.

stderr for debugging, typically, not stdout.

If you want a “human-readable” output stream, stderr would more likely fit
that bill than stdout.

On Mon, 29 Jan 2024 17:05:17 +0100, David Brown wrote:

> If you exclude obvious cases like
> phones, tablets, and smart TVs, there are many more embedded Linux
> systems that are not Android, than embedded Android systems. Those are
> all POSIX too. And yet they are all part of the 0%.

If you include them, you find that Microsoft has only something like 25%
of the computer market.

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:

> On 29/01/2024 20:10, Tim Rentsch wrote:
>
>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>
>> [...]
>>
>>> I've never used standard output for binary data.
>>> [...] it strikes me as a poor design decision.
>>
>> How so?
>
> Because the output can't be inspected by humans, and because it might
> have unusual effects if passed though systems designed to handle
> human-readable text. For instance in some systems designed to receive
> ASCII text, there is no distinction between the nul byte and "waiting
> for next data byte". Obviously this will cause difficuties if the data
> is binary.
> Also many binary formats can't easily be extended, so you can pass one
> image and that's all. While it is possible to devise a text format
> which is similar, in practice text formats usually have enough
> redundancy to be easily extended.
>
> So it's harder to correct errors, more prone to errors, and harder to
> extend.

Your reasoning is all gobbledygook. Your comments reflect only
limitations in your thinking, not any essential truth about using
standard out for binary data.

On 29/01/2024 23:27, Malcolm McLean wrote:
> On 29/01/2024 20:10, David Brown wrote:

>> Sure.  But Malcolm suggested that the "if" pattern was a special
>> distinguishing feature.  (He has already made it clear that the only
>> types of interest, in his world, are integers, floats and strings.)
>>
> No, Malcolm gave if() as an example of a distinction in a language grammar
> between functions that return a value and functions that don't. Sometimes
> functions return a value and if() still isn't allowed. Fair enough
> point.But it doesn't really detract from the point that Malcolm is makin
>

Fair enough. But that does not detract from my counter-point - I don't
think void / non-void return type is a major or helpful way to
categorise functions. As you said yourself, there is not a huge
difference between a function that returns a value directly, or one that
takes a pointer for passing the return value to the caller.

And since void / non-void return type is already a distinction made in
the way the code is written, it is not as useful a classification as you
could get from other factors that are not immediately clear from the
code or clear to the compiler (such as "has side-effects" / "depends on
side-effects" / "independent of side-effects", or "thread-safe" / "not
thread-safe").

On 30/01/2024 07:27, Tim Rentsch wrote:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>
>> On 29/01/2024 20:10, Tim Rentsch wrote:
>>
>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>>
>>> [...]
>>>
>>>> I've never used standard output for binary data.
>>>> [...] it strikes me as a poor design decision.
>>>
>>> How so?
>>
>> Because the output can't be inspected by humans, and because it might
>> have unusual effects if passed though systems designed to handle
>> human-readable text. For instance in some systems designed to receive
>> ASCII text, there is no distinction between the nul byte and "waiting
>> for next data byte". Obviously this will cause difficuties if the data
>> is binary.
>> Also many binary formats can't easily be extended, so you can pass one
>> image and that's all. While it is possible to devise a text format
>> which is similar, in practice text formats usually have enough
>> redundancy to be easily extended.
>>
>> So it's harder to correct errors, more prone to errors, and harder to
>> extend.
>
> Your reasoning is all gobbledygook. Your comments reflect only
> limitations in your thinking, not any essential truth about using
> standard out for binary data.
>
I must admit that it's nothing I have ever done or considered doing.

However standard output is designed for text and not binary ouput.
Whilst there is a "printf()" which operates on standard output by
default, there are no functions which write binary data to standard
outout by default, for example. Though of course you can pass stdout to
the regular binary output functions like fwrite().

So I'm obviously not the only person to take the view that passing
binary data to standard output is a rather odd thing to do.

I suspect the truth is that is is a bad design and I am right, but
because for some reason communications have to be via standard output,
people make the best of it and contrive that it shall work, and then
forget that essentially it is a misuse of a text stream. They are
slightly proud of their efforts and intolerant of my point.

That you couldn't actually mount a defence of your position whilst I
could also strongly implies that I am right.
--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

On 30/01/2024 10:13, Malcolm McLean wrote:
> On 30/01/2024 07:27, Tim Rentsch wrote:
>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>
>>> On 29/01/2024 20:10, Tim Rentsch wrote:
>>>
>>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>>>
>>>> [...]
>>>>
>>>>> I've never used standard output for binary data.
>>>>> [...] it strikes me as a poor design decision.
>>>>
>>>> How so?
>>>
>>> Because the output can't be inspected by humans, and because it might
>>> have unusual effects if passed though systems designed to handle
>>> human-readable text.  For instance in some systems designed to receive
>>> ASCII text, there is no distinction between the nul byte and "waiting
>>> for next data byte".  Obviously this will cause difficuties if the data
>>> is binary.
>>> Also many binary formats can't easily be extended, so you can pass one
>>> image and that's all.  While it is possible to devise a text format
>>> which is similar, in practice text formats usually have enough
>>> redundancy to be easily extended.
>>>
>>> So it's harder to correct errors, more prone to errors, and harder to
>>> extend.
>>
>> Your reasoning is all gobbledygook.  Your comments reflect only
>> limitations in your thinking, not any essential truth about using
>> standard out for binary data.
> >
> I must admit that it's nothing I have ever done or considered doing.
>
> However standard output is designed for text and not binary ouput.

Proof by repeated assertion?

/stderr/ was designed for text - it was for error messages independent
of the main output stream, precisely because stdout output was often not
human readable text but data passed on to other programs or devices.

I wonder if there is any *nix program older or simpler than "cat" - a
program that simply passes its input files or the stdin to stdout.

> Whilst there is a "printf()" which operates on standard output by
> default, there are no functions which write binary data to standard
> outout by default, for example. Though of course you can pass stdout to
> the regular binary output functions like fwrite().

There is no standard C library function that takes stderr as the default
stream. Does that mean stderr was not designed to be used at all?

"printf" exists and works the way it does because it is convenient and
useful. It can be viewed as a short-cut for "fprintf(stdout, ...".
Indeed, that is /exactly/ how the C standard describes the function.

That means the C standards acknowledge that people often want to print
out formatted text (which in no way implies plain ASCII) to stdout.
This does not mean they expect this to be the /only/ use of stdout, or
that people will not use binary outputs to stdout, any more than it
implies that text output will always be sent to stdout and not other
streams or files.

>
> So I'm obviously not the only person to take the view that passing
> binary data to standard output is a rather odd thing to do.

Many programs only write text to stdout. That does not mean writing
binary data is "odd", or that stdout was "designed" for text.

>
> I suspect the truth is that is is a bad design and I am right, but
> because for some reason communications have to be via standard output,
> people make the best of it and contrive that it shall work, and then
> forget that essentially it is a misuse of a text stream. They are
> slightly proud of their efforts and intolerant of my point.
>

Obviously you think you are right - it would be pretty silly for you to
witter on in the face of clear and mostly unanimous opposition if you
did not think you were right. That, of course, does not mean you /are/
right.

> That you couldn't actually mount a defence of your position whilst I
> could also strongly implies that I am right.

He was correct - your reasoning is gobbledygook.

If I claim grass is pink, and I know this because it is the same colour
as the sea which is also pink, then I have given a justification and a
defence of my position. That doesn't mean it is worth the pixels it is
written with, or that anyone needs to elaborate when they same I am
talking nonsense.

It is so blindingly clear and obvious that stdout is regularly used for
non-text data, and so many undeniably accurate and common examples have
been given, that your position is entirely untenable.

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>On 30/01/2024 07:27, Tim Rentsch wrote:
>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>
>>> On 29/01/2024 20:10, Tim Rentsch wrote:
>>>
>>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>>>
>>>> [...]
>>>>
>>>>> I've never used standard output for binary data.
>>>>> [...] it strikes me as a poor design decision.
>>>>
>>>> How so?
>>>
>>> Because the output can't be inspected by humans, and because it might
>>> have unusual effects if passed though systems designed to handle
>>> human-readable text. For instance in some systems designed to receive
>>> ASCII text, there is no distinction between the nul byte and "waiting
>>> for next data byte". Obviously this will cause difficuties if the data
>>> is binary.
>>> Also many binary formats can't easily be extended, so you can pass one
>>> image and that's all. While it is possible to devise a text format
>>> which is similar, in practice text formats usually have enough
>>> redundancy to be easily extended.
>>>
>>> So it's harder to correct errors, more prone to errors, and harder to
>>> extend.
>>
>> Your reasoning is all gobbledygook. Your comments reflect only
>> limitations in your thinking, not any essential truth about using
>> standard out for binary data.
> >
>I must admit that it's nothing I have ever done or considered doing.
>
>However standard output is designed for text and not binary ouput.

That was never the case. stdout is a unformatted stream of bytes
associated by default with file descriptor number one in the
application.

Long before windows was even a gleam in gates eye.

On 30/01/2024 15:00, Scott Lurndal wrote:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>> On 30/01/2024 07:27, Tim Rentsch wrote:
>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>>
>>>> On 29/01/2024 20:10, Tim Rentsch wrote:
>>>>
>>>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>>>>
>>>>> [...]
>>>>>
>>>>>> I've never used standard output for binary data.
>>>>>> [...] it strikes me as a poor design decision.
>>>>>
>>>>> How so?
>>>>
>>>> Because the output can't be inspected by humans, and because it might
>>>> have unusual effects if passed though systems designed to handle
>>>> human-readable text. For instance in some systems designed to receive
>>>> ASCII text, there is no distinction between the nul byte and "waiting
>>>> for next data byte". Obviously this will cause difficuties if the data
>>>> is binary.
>>>> Also many binary formats can't easily be extended, so you can pass one
>>>> image and that's all. While it is possible to devise a text format
>>>> which is similar, in practice text formats usually have enough
>>>> redundancy to be easily extended.
>>>>
>>>> So it's harder to correct errors, more prone to errors, and harder to
>>>> extend.
>>>
>>> Your reasoning is all gobbledygook. Your comments reflect only
>>> limitations in your thinking, not any essential truth about using
>>> standard out for binary data.
>>>
>> I must admit that it's nothing I have ever done or considered doing.
>>
>> However standard output is designed for text and not binary ouput.
>
> That was never the case. stdout is a unformatted stream of bytes
> associated by default with file descriptor number one in the
> application.
>
It is a stream of bytes at the level that the file descriptor is used to
generate a write event for a byte which can be arbitrary. But standard
output is often quickly transformed into a stream of characters.
Sometimes within the application executable.
>
> Long before windows was even a gleam in gates eye.
>
Most systems run Windows where the model of piping from standard output
to standard input of the next program is much less used than in Unix,
this is true. That sometimes generates a feeling of superiority amongst
those who use the less common, often more expensive Unix systems. It's
very silly, but that's how people think.

--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

On 30/01/2024 15:00, Scott Lurndal wrote:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:

>> I must admit that it's nothing I have ever done or considered doing.
>>
>> However standard output is designed for text and not binary ouput.
>
> That was never the case. stdout is a unformatted stream of bytes
> associated by default with file descriptor number one in the
> application.
>
> Long before windows was even a gleam in gates eye.
>

I don't know what Windows has to do with it.

The difference between text and binary byte streams is something
invented by C, so that conversions could be done for byte '\n' on
systems with alternate line-endings.

It wasn't just LF versus CRLF either. The difference with the latter is
that it is still use, /due to the popularity/ of MSDOS and WINDOWS,
while others have died out.

With C out of the picture, then CRLF was and is simply a two-byte
sequence: you write two bytes, or read two bytes.

So long as a byte has 8 bits, you can't tell whether a byte stream
represents text or binary data.

When coding however, it seems incredibly bad form to me to send what you
know is binary data (so can contain malformed UTF8, or inadvertent
escape sequences) to an output which will try to represent that on a
text display.

For such reasons, whenever I invent a binary text format, I usually
include a 26/1A byte (end-of-file) so that programs which expect a text
file will stop at that character. For example:

c:\mx>type hello.mx
MCX
c:\mx>dump hello.mx
0000: 4D 43 58 1A 01 30 2E 31 32 33 34 00 05 76 02 00

If I try it under WSL with 'cat', I get a huge bunch of crap displayed
on the screen, mixed up with long beeps whenever there's an 07 byte.

That's why binary code, not representing text, is a bad idea even on
'stdout'.

On 30/01/2024 13:03, David Brown wrote:
> On 30/01/2024 10:13, Malcolm McLean wrote:
>
> There is no standard C library function that takes stderr as the default
> stream.  Does that mean stderr was not designed to be used at all?
>
> "printf" exists and works the way it does because it is convenient and
> useful.  It can be viewed as a short-cut for "fprintf(stdout, ...".
> Indeed, that is /exactly/ how the C standard describes the function.
>
> That means the C standards acknowledge that people often want to print
> out formatted text (which in no way implies plain ASCII) to stdout. This
> does not mean they expect this to be the /only/ use of stdout, or that
> people will not use binary outputs to stdout, any more than it implies
> that text output will always be sent to stdout and not other streams or
> files.
>
Speical facilities for text don't necessarily mean that text is the only
output intended to be used, fair enough.

printf has no binary data format specifier. And as you say, the fact
that it is provided is an acknowledgement that programmers often want to
pass formatted text to standard output. The fact that there is no
similar function for standard error suggests that wanting to pass
formatted text to error is a less common requirement. Which is my
experience for the sort of programming that I do. Similarly there is no
function "write`" that passes binary data to standard output by default.
So this suggests that passing binary data to standard output is a less
common requirement. And in fact on many systems standard output will
corrupt such data by in default mode.

So these three things together - no binary data format specifer for
printf(), no binary equivalent function to printf that defaults to
standard output, and the fact that standard output will corrupt binary
data in default mode on some systems, adds up to a pretty powerful
argument for my position.
>
> If I claim grass is pink, and I know this because it is the same colour
> as the sea which is also pink, then I have given a justification and a
> defence of my position.  That doesn't mean it is worth the pixels it is
> written with, or that anyone needs to elaborate when they same I am
> talking nonsense.
>
> It is so blindingly clear and obvious that stdout is regularly used for
> non-text data, and so many undeniably accurate and common examples have
> been given, that your position is entirely untenable.
>
Do learn to think. I've given coherent, reasonable, justifications that are
open to dispute on their own terms. That you are capable of inventing an
incoherent argument on a different topic proves nothing even by analogy
except, to be fair, that it is plausible that people will make bad
arguments.

And apart from "that's how you have to do it to make a web server work
under Unix", I haven't seen much of anything in this sub thread which
constitutes a good argument for passing binary data to standard output.

--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>On 30/01/2024 15:00, Scott Lurndal wrote:
>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>> On 30/01/2024 07:27, Tim Rentsch wrote:
>>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>>>
>>>>> On 29/01/2024 20:10, Tim Rentsch wrote:
>>>>>
>>>>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>>>>>
>>>>>> [...]
>>>>>>
>>>>>>> I've never used standard output for binary data.
>>>>>>> [...] it strikes me as a poor design decision.
>>>>>>
>>>>>> How so?
>>>>>
>>>>> Because the output can't be inspected by humans, and because it might
>>>>> have unusual effects if passed though systems designed to handle
>>>>> human-readable text. For instance in some systems designed to receive
>>>>> ASCII text, there is no distinction between the nul byte and "waiting
>>>>> for next data byte". Obviously this will cause difficuties if the data
>>>>> is binary.
>>>>> Also many binary formats can't easily be extended, so you can pass one
>>>>> image and that's all. While it is possible to devise a text format
>>>>> which is similar, in practice text formats usually have enough
>>>>> redundancy to be easily extended.
>>>>>
>>>>> So it's harder to correct errors, more prone to errors, and harder to
>>>>> extend.
>>>>
>>>> Your reasoning is all gobbledygook. Your comments reflect only
>>>> limitations in your thinking, not any essential truth about using
>>>> standard out for binary data.
>>>>
>>> I must admit that it's nothing I have ever done or considered doing.
>>>
>>> However standard output is designed for text and not binary ouput.
>>
>> That was never the case. stdout is a unformatted stream of bytes
>> associated by default with file descriptor number one in the
>> application.
>>
>It is a stream of bytes at the level that the file descriptor is used to
>generate a write event for a byte which can be arbitrary. But standard
>output is often quickly transformed into a stream of characters.
>Sometimes within the application executable.

It's binary data. UTF-8, for example, is binary data. Your
statement "standard output is designed for text, not binary" is
completely false.

>those who use the less common, often more expensive Unix systems.

More expensive? In what world do you live?

bart <bc@freeuk.com> writes:
>On 30/01/2024 15:00, Scott Lurndal wrote:
>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>
>>> I must admit that it's nothing I have ever done or considered doing.
>>>
>>> However standard output is designed for text and not binary ouput.
>>
>> That was never the case. stdout is a unformatted stream of bytes
>> associated by default with file descriptor number one in the
>> application.
>>
>> Long before windows was even a gleam in gates eye.
>>
>
>I don't know what Windows has to do with it.
>
>The difference between text and binary byte streams is something
>invented by C, so that conversions could be done for byte '\n' on
>systems with alternate line-endings.

No, it was invented to support windows CRLF line endings.

Regardless of your digression, stdout is still an unformatted
stream of bytes. Any structure on that stream is imposed
by the -consumer- of those bytes.

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>On 30/01/2024 13:03, David Brown wrote:
>> On 30/01/2024 10:13, Malcolm McLean wrote:
>>
>> There is no standard C library function that takes stderr as the default
>> stream.  Does that mean stderr was not designed to be used at all?
>>
>> "printf" exists and works the way it does because it is convenient and
>> useful.  It can be viewed as a short-cut for "fprintf(stdout, ...".
>> Indeed, that is /exactly/ how the C standard describes the function.
>>
>> That means the C standards acknowledge that people often want to print
>> out formatted text (which in no way implies plain ASCII) to stdout. This
>> does not mean they expect this to be the /only/ use of stdout, or that
>> people will not use binary outputs to stdout, any more than it implies
>> that text output will always be sent to stdout and not other streams or
>> files.
>>
>Speical facilities for text don't necessarily mean that text is the only
>output intended to be used, fair enough.

Even text is just an unformatted stream of bytes. It is the ultimate
consumer of that text that imposed structure on it (e.g. by treating
it as ASCII, UTF-16, UTF-8, UTF-32, EBCDIC, et cetera, et alia, und so weiter)

>
>printf has no binary data format specifier.

%s? Simply copies non-nul bytes. That's almost as binary as
one can get, it certainly isn't restricted to printable characters.

And of course, there are putc and putchar.

Not to mention using printf where the format string argument
includes binary data.

<snip>
> The fact that there is no
>similar function for standard error

fprintf(stderr, "%s", binary_data_with_no_embedded_nul_bytes);

>. Similarly there is no
>function "write`" that passes binary data to standard output by default.

In the real world, and in the world the C was created to support
there are several functions (write, pwrite, mmap, aio_listio, aio_read,
aio_write et cetera, et alia, und so wieter).

Most of which existed before 1989.

On 30/01/2024 15:54, Scott Lurndal wrote:
> bart <bc@freeuk.com> writes:
>> On 30/01/2024 15:00, Scott Lurndal wrote:
>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>
>>>> I must admit that it's nothing I have ever done or considered doing.
>>>>
>>>> However standard output is designed for text and not binary ouput.
>>>
>>> That was never the case. stdout is a unformatted stream of bytes
>>> associated by default with file descriptor number one in the
>>> application.
>>>
>>> Long before windows was even a gleam in gates eye.
>>>
>>
>> I don't know what Windows has to do with it.
>>
>> The difference between text and binary byte streams is something
>> invented by C, so that conversions could be done for byte '\n' on
>> systems with alternate line-endings.
>
> No, it was invented to support windows CRLF line endings.

You just want to have a go at Windows don't you?

I was using CRLF line-endings in 1970s, they weren't an invention of
Windows, which didn't exist until the mid-80s and didn't become popular
until the mid-90s.

So, how did C deal with CRLF in all those non-Windows settings?

> Regardless of your digression, stdout is still an unformatted
> stream of bytes. Any structure on that stream is imposed
> by the -consumer- of those bytes.

Of course. But it still a bad idea to write actual output that you KNOW
does not represent text, to a consumer that will expect text.

For example to a terminal window, which can happen if you forget to
redirect it.

On Tue, 30 Jan 2024 16:06:02 +0000, Scott Lurndal wrote:

> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>On 30/01/2024 13:03, David Brown wrote:
>>> On 30/01/2024 10:13, Malcolm McLean wrote:
>>>
>>> There is no standard C library function that takes stderr as the default
>>> stream.  Does that mean stderr was not designed to be used at all?
>>>
>>> "printf" exists and works the way it does because it is convenient and
>>> useful.  It can be viewed as a short-cut for "fprintf(stdout, ...".
>>> Indeed, that is /exactly/ how the C standard describes the function.
>>>
>>> That means the C standards acknowledge that people often want to print
>>> out formatted text (which in no way implies plain ASCII) to stdout. This
>>> does not mean they expect this to be the /only/ use of stdout, or that
>>> people will not use binary outputs to stdout, any more than it implies
>>> that text output will always be sent to stdout and not other streams or
>>> files.
>>>
>>Speical facilities for text don't necessarily mean that text is the only
>>output intended to be used, fair enough.
>
> Even text is just an unformatted stream of bytes. It is the ultimate
> consumer of that text that imposed structure on it (e.g. by treating
> it as ASCII, UTF-16, UTF-8, UTF-32, EBCDIC, et cetera, et alia, und so weiter)
>
>>
>>printf has no binary data format specifier.
>
> %s? Simply copies non-nul bytes. That's almost as binary as
> one can get, it certainly isn't restricted to printable characters.
>
> And of course, there are putc and putchar.
>
> Not to mention using printf where the format string argument
> includes binary data.
>
> <snip>
>> The fact that there is no
>>similar function for standard error
>
> fprintf(stderr, "%s", binary_data_with_no_embedded_nul_bytes);

Or, better yet, fwrite(), which can write to any output stream[1],
including stdout and stderr.

[1] At least, the C standard does not impose any restriction on
which stream(s) fwrite() can access, other than that they must
be writable.

>
>>. Similarly there is no
>>function "write`" that passes binary data to standard output by default.

fwrite(buffer,sizeof *buffer,1,stdout);

> In the real world, and in the world the C was created to support
> there are several functions (write, pwrite, mmap, aio_listio, aio_read,
> aio_write et cetera, et alia, und so wieter).
>
> Most of which existed before 1989.

--
Lew Pitcher
"In Skills We Trust"

On 30/01/2024 16:49, Malcolm McLean wrote:
> On 30/01/2024 13:03, David Brown wrote:
>> On 30/01/2024 10:13, Malcolm McLean wrote:
>>
>> There is no standard C library function that takes stderr as the
>> default stream.  Does that mean stderr was not designed to be used at
>> all?
>>
>> "printf" exists and works the way it does because it is convenient and
>> useful.  It can be viewed as a short-cut for "fprintf(stdout, ...".
>> Indeed, that is /exactly/ how the C standard describes the function.
>>
>> That means the C standards acknowledge that people often want to print
>> out formatted text (which in no way implies plain ASCII) to stdout.
>> This does not mean they expect this to be the /only/ use of stdout, or
>> that people will not use binary outputs to stdout, any more than it
>> implies that text output will always be sent to stdout and not other
>> streams or files.
>>
> Speical facilities for text don't necessarily mean that text is the only
> output intended to be used, fair enough.
>
> printf has no binary data format specifier.

Mixing binary data with formatted text data is very unlikely to be
useful. fwrite() is perfectly good for writing binary data - it would
make no sense to have some awkward printf specifier to do this. (What
would the specifier even be? It would need to take two items of data -
a pointer and a length - and thus be very different from existing
specifiers.)

> And as you say, the fact
> that it is provided is an acknowledgement that programmers often want to
> pass formatted text to standard output.

Yes.

> The fact that there is no
> similar function for standard error suggests that wanting to pass
> formatted text to error is a less common requirement.

stderr is a newer invention than stdout and stdin. Perhaps no one
bothered to add such a function to the standard library because
"fprintf(stderr..." is not particularly difficult to write.

> Which is my
> experience for the sort of programming that I do. Similarly there is no
> function "write`" that passes binary data to standard output by default.

What would that gain? One fewer parameters to fwrite() ?

You are reading /way/ too much into the existence or non-existence of
short-cut functions in the C standard library.

> So this suggests that passing binary data to standard output is a less
> common requirement. And in fact on many systems standard output will
> corrupt such data by in default mode.
>
> So these three things together - no binary data format specifer for
> printf(), no binary equivalent function to printf that defaults to
> standard output, and the fact that standard output will corrupt binary
> data in default mode on some systems, adds up to a pretty powerful
> argument for my position.
>>
>> If I claim grass is pink, and I know this because it is the same
>> colour as the sea which is also pink, then I have given a
>> justification and a defence of my position.  That doesn't mean it is
>> worth the pixels it is written with, or that anyone needs to elaborate
>> when they same I am talking nonsense.
>>
>> It is so blindingly clear and obvious that stdout is regularly used
>> for non-text data, and so many undeniably accurate and common examples
>> have been given, that your position is entirely untenable.
>>
> Do learn to think. I've given coherent, reasonable, justifications that are
> open to dispute on their own terms.

No, you haven't. You have taken your own experience of C programming in
a limited niche field, and extrapolated wildly to assume it applies to
all C programming. You have totally failed to consider extremely common
cases where binary stdout output is used - utility programs that anyone
who uses the Linux command line regularly makes use of dozens of times a
day. You have taken the existence or non-existence of certain standard
C library functions as though they were hard rules about how stdout was
"designed", or hard rules about what is "normal" and what is "odd" in C
programming.

Nothing of that was reasonable or justified.

> That you are capable of inventing an
> incoherent argument on a different topic proves nothing even by analogy
> except, to be fair, that it is plausible that people will make bad
> arguments.
>
> And apart from "that's how you have to do it to make a web server work
> under Unix", I haven't seen much of anything in this sub thread which
> constitutes a good argument for passing binary data to standard output.
>

Then you haven't bothered looking at any of the posts in this thread
branch, and it is therefore not worth trying to educate you by repeating
the same things.

On 30/01/2024 16:06, Scott Lurndal wrote:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>> On 30/01/2024 13:03, David Brown wrote:
>>> On 30/01/2024 10:13, Malcolm McLean wrote:
>>>
>>> There is no standard C library function that takes stderr as the default
>>> stream.  Does that mean stderr was not designed to be used at all?
>>>
>>> "printf" exists and works the way it does because it is convenient and
>>> useful.  It can be viewed as a short-cut for "fprintf(stdout, ...".
>>> Indeed, that is /exactly/ how the C standard describes the function.
>>>
>>> That means the C standards acknowledge that people often want to print
>>> out formatted text (which in no way implies plain ASCII) to stdout. This
>>> does not mean they expect this to be the /only/ use of stdout, or that
>>> people will not use binary outputs to stdout, any more than it implies
>>> that text output will always be sent to stdout and not other streams or
>>> files.
>>>
>> Speical facilities for text don't necessarily mean that text is the only
>> output intended to be used, fair enough.
>
> Even text is just an unformatted stream of bytes. It is the ultimate
> consumer of that text that imposed structure on it (e.g. by treating
> it as ASCII, UTF-16, UTF-8, UTF-32, EBCDIC, et cetera, et alia, und so weiter)
>
No. If we know that text is ASCII it is not highly structured. But it is
not true that there is no structure and any value can occur in any
position as with true binary data.

>>
>> printf has no binary data format specifier.
>
> %s? Simply copies non-nul bytes. That's almost as binary as
> one can get, it certainly isn't restricted to printable characters.
>
C plays fast and loose with the char type. But you can't pass embedded
nuls. These are so common in binary data that in practis=ce you can't
use %s for binary data at all.
>
> And of course, there are putc and putchar.
>
putc doesn't write by default to standard output. But putchar is a
counter-example, and finally someone has made something which
constitutres a point. But look at the name. "put char". Does that sound
like a function intended for binary or text data? But C plays fast and
loose with character data, and you do have a point here.
>
> Not to mention using printf where the format string argument
> includes binary data.
>
Well OK. That is a way of defeating printf(). But again, how would you
embed a nul byte?
>
> In the real world, and in the world the C was created to support
> there are several functions (write, pwrite, mmap, aio_listio, aio_read,
> aio_write et cetera, et alia, und so wieter).
>
> Most of which existed before 1989.
>
I don't think any of those write binary output by default to standard
output. Some of them take a file descriptor which can be standard output.
Then obviously at a very low level, interfaces tend to be binary. The
ultimate physical reality is usually electronic signals which can take
one of two values. That's not we're talking about.
--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

On 30/01/2024 17:10, bart wrote:
> On 30/01/2024 15:54, Scott Lurndal wrote:
>> bart <bc@freeuk.com> writes:
>>> On 30/01/2024 15:00, Scott Lurndal wrote:
>>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>>
>>>>> I must admit that it's nothing I have ever done or considered doing.
>>>>>
>>>>> However standard output is designed for text and not binary ouput.
>>>>
>>>> That was never the case.  stdout is a unformatted stream of bytes
>>>> associated by default with file descriptor number one in the
>>>> application.
>>>>
>>>> Long before windows was even a gleam in gates eye.
>>>>
>>>
>>> I don't know what Windows has to do with it.
>>>
>>> The difference between text and binary byte streams is something
>>> invented by C, so that conversions could be done for byte '\n' on
>>> systems with alternate line-endings.
>>
>> No, it was invented to support windows CRLF line endings.
>
> You just want to have a go at Windows don't you?
>
> I was using CRLF line-endings in 1970s, they weren't an invention of
> Windows, which didn't exist until the mid-80s and didn't become popular
> until the mid-90s.

CRLF line endings were the invention of printers or teletype machines.
It took time to move print heads from the end of one line to the
beginning of the next, and separating the "carriage return" and "line
feed" commands made timings easier. It also let printer implementers
handle the two operations independently - occasionally people would want
to do one but not the other.

The use of CRLF as a standard for line endings in files was, I believe,
from CP/M - which came after Unix and Multics, which had standardised on
LF line endings. (Most OS's before that made things up as they choose,
rather than being "standard", or used record-based files, punched cards,
etc.)

So CRLF precedes Windows quite significantly.

(I have no idea why Macs picked CR - perhaps they just wanted to be
different.)

>
> So, how did C deal with CRLF in all those non-Windows settings?
>

The difference between "text" and "binary" streams in C is, in practice,
up to the implementation. That can be the implementation of the C
library, or the OS functions (or DLLs/SOs) that the C library calls.
The norm is that you use "\n" for line endings in the C code - what
happens after that, for text streams, is beyond C.

The reason C distinguishes between text and binary streams is that some
OS's distinguish between them.

>
>> Regardless of your digression, stdout is still an unformatted
>> stream of bytes.   Any structure on that stream is imposed
>> by the -consumer- of those bytes.
>
> Of course. But it still a bad idea to write actual output that you KNOW
> does not represent text, to a consumer that will expect text.
>

That's just a specific example of "it's a bad idea for a program to
behave in a way that a reasonable user would not expect". Which is, of
course, true - but not a big surprise.

> For example to a terminal window, which can happen if you forget to
> redirect it.

If the program can reasonably be expected to generate binary output,
then it is the user's fault if they do this accidentally. Examples
shown in this thread include cat and zcat - that's what these programs do.

Sometimes people make mistakes, and try to "cat" (or "type") non-text
files. Mistakes happen.

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>On 30/01/2024 16:06, Scott Lurndal wrote:
>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>> On 30/01/2024 13:03, David Brown wrote:
>>>> On 30/01/2024 10:13, Malcolm McLean wrote:
>>>>
>>>> There is no standard C library function that takes stderr as the default
>>>> stream.  Does that mean stderr was not designed to be used at all?
>>>>
>>>> "printf" exists and works the way it does because it is convenient and
>>>> useful.  It can be viewed as a short-cut for "fprintf(stdout, ...".
>>>> Indeed, that is /exactly/ how the C standard describes the function.
>>>>
>>>> That means the C standards acknowledge that people often want to print
>>>> out formatted text (which in no way implies plain ASCII) to stdout. This
>>>> does not mean they expect this to be the /only/ use of stdout, or that
>>>> people will not use binary outputs to stdout, any more than it implies
>>>> that text output will always be sent to stdout and not other streams or
>>>> files.
>>>>
>>> Speical facilities for text don't necessarily mean that text is the only
>>> output intended to be used, fair enough.
>>
>> Even text is just an unformatted stream of bytes. It is the ultimate
>> consumer of that text that imposed structure on it (e.g. by treating
>> it as ASCII, UTF-16, UTF-8, UTF-32, EBCDIC, et cetera, et alia, und so weiter)
>>
>No. If we know that text is ASCII it is not highly structured.

ASCII is, of course, structured.

David Brown <david.brown@hesbynett.no> writes:
>On 30/01/2024 16:49, Malcolm McLean wrote:
>
>> The fact that there is no
>> similar function for standard error suggests that wanting to pass
>> formatted text to error is a less common requirement.
>
>stderr is a newer invention than stdout and stdin.

c'est what?

On 30/01/2024 16:25, David Brown wrote:
> On 30/01/2024 16:49, Malcolm McLean wrote:
>>
>> Which is my experience for the sort of programming that I do.
[stderr less used than stdout]
>> Similarly there is no function "write`" that passes binary data to
>> standard output by default.
>
> What would that gain?  One fewer parameters to fwrite() ?
>
Yes. printf() could easily have been omitted and fprintf() only
provided. But because putting text on standard output is such a common
requirement, it's worth incuding it in the standard library. Purely to
save the file stream parameter. Binary output to standard output, not
used enough to be worth doing this.
--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

On 30.01.2024 17:55, Scott Lurndal wrote:
> David Brown <david.brown@hesbynett.no> writes:
>>
>> stderr is a newer invention than stdout and stdin.
>
> c'est what?
>

(The posting frequency is amazing, and many texts
filled with countless crude and hilarious claims;
it would take too much time to answer them all.)[*]

What we certainly know for sure is...

All these channels are about 6000 years old.[**]

On the eighth day The Lord gave us stdin(0),
thus we were able to receive divine wisdom.
On the ninth day The Lord gave us stdout(1),
thus we could praise him for the wisdom he gave us.
But The Lord saw that it was not good.
So on the tenth day The Lord gave us stderr(2),
and thus we further knew that we are erring.

This apocryphal text undoubtedly proves what yet
had been only unproven claims.

Janis

[*] See also: https://xkcd.com/386/

[**] Some say that must be a fixed point number,
and it's effectively 60,00 years (or 60.00 in US
format). But anyway, "The Word" is what counts.

On 30/01/2024 16:49, David Brown wrote:

>> You just want to have a go at Windows don't you?
>>
>> I was using CRLF line-endings in 1970s, they weren't an invention of
>> Windows, which didn't exist until the mid-80s and didn't become
>> popular until the mid-90s.
>
> CRLF line endings were the invention of printers or teletype machines.
> It took time to move print heads from the end of one line to the
> beginning of the next, and separating the "carriage return" and "line
> feed" commands made timings easier.  It also let printer implementers
> handle the two operations independently - occasionally people would want
> to do one but not the other.
>
> The use of CRLF as a standard for line endings in files was, I believe,
> from CP/M - which came after Unix and Multics, which had standardised on
> LF line endings.  (Most OS's before that made things up as they choose,
> rather than being "standard", or used record-based files, punched cards,
> etc.)
>
> So CRLF precedes Windows quite significantly.
>
> (I have no idea why Macs picked CR - perhaps they just wanted to be
> different.)
>
>>
>> So, how did C deal with CRLF in all those non-Windows settings?
>>
>
> The difference between "text" and "binary" streams in C is, in practice,
> up to the implementation.  That can be the implementation of the C
> library, or the OS functions (or DLLs/SOs) that the C library calls. The
> norm is that you use "\n" for line endings in the C code - what happens
> after that, for text streams, is beyond C.
>
> The reason C distinguishes between text and binary streams is that some
> OS's distinguish between them.
>
>>
>>> Regardless of your digression, stdout is still an unformatted
>>> stream of bytes.   Any structure on that stream is imposed
>>> by the -consumer- of those bytes.
>>
>> Of course. But it still a bad idea to write actual output that you
>> KNOW does not represent text, to a consumer that will expect text.
>>
>
> That's just a specific example of "it's a bad idea for a program to
> behave in a way that a reasonable user would not expect".  Which is, of
> course, true - but not a big surprise.
>
>> For example to a terminal window, which can happen if you forget to
>> redirect it.
>
> If the program can reasonably be expected to generate binary output,
> then it is the user's fault if they do this accidentally.  Examples
> shown in this thread include cat and zcat - that's what these programs do.
>
> Sometimes people make mistakes, and try to "cat" (or "type") non-text
> files.  Mistakes happen.

If you routinely write pure binary data to stdout, then users are going
to see garbage a lot more often.

I gave an example earlier when displaying a binary file with 'type' was
better-behaved than with 'cat', since 'type' stops at the first 1A byte.

I used this in my binary formats by adding 1A after the signature, so
you if you attempted to type it out, it wouldn't go mad. Here's another
example:

c:\sc>type tree.scd
SCD

(.scd is a binary file containing CAD drawing data.)

If I again do that with 'cat' under WSL, it's goes even crazier. In
starts to try and interpret of the output as commands (with what
program, I don't know), with lots of Bell sounds, and I can't get back
to the WSL prompt.

It's just very, very sloppy.

Using 'type' on a binary file without a 1A deliberately added as a
barrier, can have similar problems, but it will at least stop when 1A is
seen. For example:

c:\jpeg>type card2.jpg
����JFIF

HH���ExifM
n


I get one line of output. What does 'cat' do? I haven't yet tried it.
Now that I do, then yep, a bunch of crap disappearing off the top of the
screen.

This is the last part of it:

-----------------------------
root@XXX:/mnt/c/jpeg# cat card2.jpg
.....
��Ny�6��G�W������o���N#qi=�>�˧5+_�,�l������*�����}����3Tg�sd����J�&��{��^7��x)j��\�`�BAFxk6k{K���_�>
>�͚͞�O��
��{J}bT��Nl��Y�ث���:����#�jƾ�`T�s
$�b��Y�Lث��root@XXX:/mnt/c/jpeg# 61;6;7;22;23
3;24;28;32;42c
61: command not found
6: command not found
7: command not found
22: command not found
23: command not found
24: command not found
28: command not found
32: command not found

Command '42c' not found, did you mean:

command 'g2c' from deb goo (0.155+ds-1)
command 'f2c' from deb f2c (20160102-1)

Try: apt install <deb name>

root@XXX:/mnt/c/jpeg#

------------------------------------

It stopped a third of the way down showing ... 24;28;32;42c (I didn't
notice the prompt that was hidden in there), then I typed Enter, which
generated that other garbage.

This is really poor. I know you will not agree with that; you can't do
as you would then be against the entire ethos of Unix which is that
everything is done by piping binary data between processes.

On 29/01/2024 21:00, Keith Thompson wrote:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>> On 29/01/2024 16:18, David Brown wrote:
>>> On 28/01/2024 20:49, Malcolm McLean wrote:
>>>> On 28/01/2024 18:24, David Brown wrote:
>>>> I'd expect that most general purpose programs written by Norwegians
>>>> use an English interface, even if it isn't really expected that the
>>>> program will find an audience beyond some users in Norway. Except
>>>> of course for programs which in some way are about Norway.
>>> Why?
>>>
>> Generally programmers are educated people and educated people use
>> English for serious purposes. Not always of course and Norway might be
>> an exception. But I'd expect that in a Norweigian university, for
>> example, it would be forbidden to document a program in Norwegian or
>> to use non-English words for identifiers. And probably the same in a
>> large Norwegina company. I might be wrong about that and I have never
>> visited Norway or worked for a Norweigian employer (and obviously I
>> couldn't do so unless the policy I expect was followed).
>
> You assert that "educated people use English for serious purposes".
> I don't have the experience to refute that claim, but I suspect
> it's arrogant nonsense. I could be wrong, of course.

Everything which is at all intellectually serious is these days written
in English. It's the new Latin. It's the language all educated people
use to communicate with each other when discussing scientific,
philosophical, or scholarly matters. And also technical matters to a
large extent.
There are a few exceptions but very few. I remember a discussion about
whether you could get away with organising a scientific conference in
French, in France, and the conclusion was that you could not. Even in
France. However the French are very reluctant to concede, which is why
the discussion took place at all.

If a large Norwegian company allows programmers to document software in
Norwegian, then it cannot employ non-Norwegian programmers to work on
it. So I would imagine that this would be forbidden, But I've never
actually worked for a Norwegian company and I don't actually know. David
Brown, to be fair, does work for a Norwegian company so he might know
better. But he asks "why?" and I gave the reason.

--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm