Re: NetBSD bug/misbehavior in vdprintf

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

On Sat, Aug 29, 2020 at 08:25:42AM -0700, Rob Newberry wrote:
> >>> 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.
> 
> Is the interface any different for fprintf than dprintf?  Does fprintf
> (by virtue of having a FILE* instead of just a descriptor) have the
> ability to deal with those errors better?

It is, there is always some internal buffering for fprintf, so in
principle you can flush, ack the error, flush again etc.

Joerg