Current-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: NetBSD bug/misbehavior in vdprintf

On Fri, Aug 28, 2020 at 10:02:51PM -0000, Christos Zoulas wrote:
> In article <>,
> Rob Newberry  <> 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.


Home | Main Index | Thread Index | Old Index