Re: NetBSD bug/misbehavior in vdprintf

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Sat, 29 Aug 2020 20:09:34 -0000 (UTC)
    From:        christos%astron.com@localhost (Christos Zoulas)
    Message-ID:  <rieclu$bi9$1%ciao.gmane.io@localhost>

  | implies that stdio should work with non-blocking file descriptors.

Depending upon your definition of "work" that might be stretching what it
says a little.   At the very least it needs to work as well as write()
works, taking into account buffering.

  | Retrying after clearerr(3), should work.

I don't think that is ever stated (even implied) though certainly
it would be useful to work that way.

Of course dprintf() is the same - but just like all I/O using fd's
instead of FILE's the user is responsible for the data and its management
(including a resend if EAGAIN was returned the first time).

What is not clear about dprintf (about how it should work, or actually
works) is what happens if an EAGAIN happens after writing some of the
output, but not all of it - there is no way to return both the error,
and the number of bytes written, and no sane way to redo the same request
but skip the first N bytes of output, even if we could discover N.

Using dprintf with non-blocking I/O is probably foolish - better would
be sprintf() (or one of its cousins) and write().   Foolish doesn't need
to mean not allowed however.

kre