Path: csiph.com!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups: comp.lang.c
Subject: Re: iso646.h
Date: Tue, 30 Jan 2024 23:18:21 -0800
Organization: A noiseless patient Spider
Lines: 58
Message-ID: <865xzaas3m.fsf@linuxsc.com>
References: <uokhnk$eiln$1@dont-email.me> <87frym7l3p.fsf@nosuchdomain.example.com> <uot08a$278i2$1@dont-email.me> <uotmed$2ack6$2@dont-email.me> <up17f9$313qt$4@dont-email.me> <up197h$31jct$1@dont-email.me> <up1t0r$37v5a$4@dont-email.me> <up2mor$3bjgb$1@dont-email.me> <up2ogd$3bs86$1@dont-email.me> <up3r9c$3hbk7$10@dont-email.me> <up47gj$3jfg4$1@dont-email.me> <87jznu1c4v.fsf@nosuchdomain.example.com> <up4ceh$3k4b8$1@dont-email.me> <up5fk6$3t99q$6@dont-email.me> <up5u8c$blo$1@dont-email.me> <up6655$1l8b$2@dont-email.me> <up6b3v$2ff9$1@dont-email.me> <86zfwnc34o.fsf@linuxsc.com> <up97vr$l025$1@dont-email.me> <86il3bb7rb.fsf@linuxsc.com> <upaej6$u5ag$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Info: dont-email.me; posting-host="fb4244b8d2c04d3d864a981f3fa61ba0"; logging-data="1508199"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+7KmXrBf4TrLaG7nONU3Fr2IqStYcnXqs="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:H48ZDPeukeTQlxolA9L5pOFmcXs= sha1:SxbVVBc/OF0wM6QUWsXyo1J19kw=
Xref: csiph.com comp.lang.c:381312

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

Simple example (disclaimer: not tested):

    ssh foo 'cd blah ; tar -cf - . | gzip -c' | \
       (mkdir foo.blah ; cd foo.blah ; gunzip -c | tar -xf -)

Of the five main programs in this command, four are using
standard out to send binary data:

    tar -cf - .
    gzip -c
    ssh foo [...]
    gunzip -c

The tar -xf - at the end reads binary data on standard in
but doesn't output any (or anything else for that matter).

It is FAR more cumbersome to accomplish what this command
is doing without sending binary data through standard out.
Anyone who doesn't understand this doesn't understand Unix.