After the last line is read from the fileDescriptor the callee will call
readLine once last time. If the (uninitialized) buffer just happened to
contain '\r' then this method would increment bytesReceived, then
decrement it (because it has '\r' in it), then decrement it agin and
assign a null byte to the byte before the buffer (stepping on who knows
what). Then it would return the '\r'. Then, since it received something,
the callee would call readLine again, malloc would give the same buffer
it did before (with the '\r') and everything would repeat.
- initialize the buffer
- increment bytesReceived only if a byte is actually received
- don't do any work in the loop if there were no bytes received
- EINTR is a recoverable error, just reread
- give the actual reason for an error rather than some random string
- free the buffer when a newline is found or when there is an error
EINTR errors are recoverable, just need to read() again.
Randomly while looking at files in the file browser the contents view will be empty or files will not be shown when clicking a discloser triangle. Seems to happen more when running in XCode than when running by itself.
We used to fall back on the ASCII encoding if UTF-8 did not work out. However,
this causes its own problems; ASCII is only valid for the lower 7 bytes. We
solve this by using Latin-1, which should have a valid character for every
byte sequence
If a commit had invalid UTF-8 characters in them -- like one in git.git for
example -- then the revparsing would stop halfway through. This patch first
tries UTF-8 enconding, and if that fails, falls back to ASCII encoding.
Nathan Kinsinger