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

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

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


-- Unsubscribe info: Problem reports: Documentation: FAQ:

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