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