BUG: alternatives
Christopher Faylor
cgf-no-personal-reply-please@cygwin.com
Sun Nov 6 13:43:00 GMT 2005
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/
More information about the Cygwin
mailing list