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