Re: NetBSD bug/misbehavior in vdprintf

[Joerg Sonnenberger <joerg%bec.de@localhost>]

On Fri, Aug 28, 2020 at 10:02:51PM -0000, Christos Zoulas wrote:
> In article <AF7E402C-CEAD-47B8-A916-4BE4259A6616%mac.com@localhost>,
> Rob Newberry  <robthedude%mac.com@localhost> wrote:
> >(Also posting to tech-userlevel...)
> >
> >
> >NetBSD's implementation of vdprintf makes a special check -- if the
> >descriptor is in non-blocking mode, it needs to be a regular file (I
> >think I read that code correctly).  But it apparently doesn't have this
> >check problem for vfprintf.  I think it's been there a long time (since
> >the introduction of vdprintf), but it makes vdprintf behave differently
> >than vfprintf.  In my view, "vfprintf( FILE, ...)" and "vdprintf(
> >fileno( FILE ), ... )" ought to behave the same -- but they don't (on
> >NetBSD) if "fileno( FILE )" has been marked non-blocking and it's not a
> >regular file.
> 
> You are right, it should work and I removed the test.

Isn't the situation a bit more complicated? Normally, stdio will ensure
data isn't just lost for non-blocking sockets on the blocking condition.
But I don't think the whole dprintf interface allows dealing with error
conditions in any sane way.

Joerg