On Sun, Nov 06, 2005 at 12:50:11AM -0500, Charles Wilson wrote: >Gary R. Van Sickle wrote: >>I'm not sure the test is actually valid anyway. IIRC (and I may not, POSIX >>may prove me wrong here), there's no guarantee that read() will return the >>number of bytes you requested, so at a minium to make this 100% correct >>you'd have to do something like this: >> >>// Read entire file >>while(read(...) != 0) >>{ >>} >> >>// Check if there was a read() failure or if it just ran out of bytes to >>read. >>[...] > >From my reading of >http://www.opengroup.org/onlinepubs/007908799/xsh/read.html it appears >that, while read doesn't always return the number of bytes requested, >when it DOES return something other than numbytesrequested in THIS >particular application we want to flag an error, and bail. > >e.g. a signal was received, there weren't enough bytes ready (timeout? >disk hardware error?), or we prematurely reached EOF...
A signal shouldn't cause a truncated read when retrieving data from disk on cygwin or linux. I think the only sane way to handle this is to put the read in a loop and realloc the buffer as needed as long as the read continues to return > 0. It's obviously pretty racy to get the size of the file and then expect that you'll be able to read in exactly that many bytes. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/