BUG: alternatives

[Charles Wilson]

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...

> Something like (2) is the only way to do things correctly under any and all
> circumstances.  What I usually do is accept either an '\r' or an '\n' as an
> EOL character, and then ignore blank lines.  That way, whichever combination
> of '\r's and '\n's you have, even abberations like '\r\r\n' which
> occaisionally show up, you can read it with no problem.

The problem with this approach is that blank lines are significant in 
the '/var/lib/alternatives/*' file format.  Silly, but I didn't come up 
with it...

--
Chuck


--
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/