[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 <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.
Main Index |
Thread Index |