On Sun, Jan 22, 2023 at 02:44:47PM +0100, S??ren Tempel wrote:
> Hi Otto,
>
> Thanks for your fast reply. Remarks below.
>
> Otto Moerbeek <o...@drijf.net> wrote:
> > Some observations:
> >
> > - You are reading from stdout.
>
> Sorry, small mistake that slipped in while reformatting the code for the ML.
>
> > - Since you are reading one char at the time, the moment the EOF is
> > processed the buffer is empty, so no pending chars. I'll take that as
> > a valid interpretation of Posix.
>
> I am no expert on the interpretation of the POSIX standard, but Section
> 11.1.9 explicitly talks about "bytes waiting to be read" and not about
> bytes in the buffer of the process "the moment the EOF is processed".
>
> > - If you modify your program to read 4 chars at the time (see below),
> > you will see your expected behaviour.
> >
> > -Otto
> >
> > #include <unistd.h>
> > #include <stdio.h>
> >
> > int main(void)
> > {
> > for (;;) {
> > char c[4];
> > ssize_t r = read(0, c, sizeof(c));
> > if (r == 0)
> > break; /* EOF */
> > printf("read: %zd chars\n", r);
> > }
> > }
>
> While this program works for the input "foo<ctrl-d>" it does (just like
> my original program) also terminate on the input "foo1<ctrl-d>" since
> the buffer is, once again, empty when the EOF is received. However, POSIX
> mandates that read(2) should only return a byte count of zero if "the
> EOF occurred at the beginning of a line" and for the input
> "foo1<ctrl-d>" the EOF does not occur at the beginning of the line but
> OpenBSD read(2) still returns zero.
>
> Greetings,
> S??ren
I'd have to check a FreeBSD machine (I can do so tomorrow), but macOS
follows the same logic as OpenBSD. So this maye vey well be
established BSD behaviour.
The text in our man page are almost verbatim copies of the Posix text
(same for the man pages of macOS and FreeBSD). I do wonder why they do
not describe the slightly different BSD semantics.
I'll post the FreeBSD results tomorrow.
-Otto
