Date: Mon, 5 Jul 2021 00:41:23 +0100
From: Harald van Dijk <a...@gigawatt.nl>
Message-ID: <88337ff9-c726-c563-4d4f-3fa74d964...@gigawatt.nl>
| I was looking at the HTML version. Aside from its search function, you
| can find it there under System Interfaces (top left frame), then System
| Interfaces (bottom left frame), then stdout (bottom left frame).
Thanks, exactly what I needed to know,
System Interfaces (top left frame) is XSH
System Interfaces (bottom left frame) is XSH.3
and stdout (bottom left frame) is XSH 3.stdin
(the stdin/stderr/stdout pages are all the same, the one identified is
stdin, probably because it is 0, though stderr would be more logical, as
normally the lexically first is chosen when there are multiple interfaces
in a page).
I never even thought of looking there, I don't regard those things as
being system interfaces I guess, I was looking mostly in XBD (definitions,
headers, etc).
But that's actually a very interesting page:
63796 CX At program start-up, three streams shall be predefined and already
open: stdin (standard input, |
63797 for conventional input) for reading, stdout (standard output, for
conventional output) for |
63798 writing, and stderr (standard error, for diagnostic output) for
writing. When opened, stderr shall |
63799 not be fully buffered; stdin and stdout shall be fully buffered if
and only if the file descriptor |
63800 associated with the stream is determined not to be associated with
an interactive device.
Once again, buffering exists and is known to exist - and what's more,
the standard actually *required* stdout to be buffered whenever it is
not associated with a terminal (which is no big surprise, as that's how
systems have always worked).
Note that there's nothing in there that even hints that applications are
responsible for flushing the buffers themselves, that is, and always has
been an automated part of exit processing (and is largely why _exit()
exists).
kre
