Re: NetBSD bug/misbehavior in vdprintf

[Brian Buhrow <buhrow%nfbcal.org@localhost>]

	hello.  I'm pretty sure fpritf can return an error that means there
was an i/o error or that something about the underlying file descriptor
needs investigating.
-Brian

On Aug 29,  8:25am, Rob Newberry wrote:
} Subject: Re: NetBSD bug/misbehavior in vdprintf
} >>> 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?
} 
} 
} 
>-- End of excerpt from Rob Newberry