This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: BUG: alternatives

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
>From my reading of 
> 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.


Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]