CanonicalizePath handles \ on Windows

Have CanonicalizePath handle \ on Windows. It's slightly slower to do so, so compensate for that by improving ReadFile to not use text mode (which is a bit slower), and then fixing the lexer to accept \r (it was previously relying on reading files in text mode to remove '\r's).

Linux (\r didn't cause regression):

before:
real	0m0.675s
real	0m0.681s
real	0m0.698s
real	0m0.711s


after:
real	0m0.672s
real	0m0.680s
real	0m0.687s
real	0m0.706s


Windows (ReadFile compensates for \ regression)

before: 1254337us
before: 1254538us
before: 1222909us

after: 1228009us
after: 1226726us
after: 1219994us

Squashed version of https://github.com/sgraham/ninja/compare/canon-win

This fixes #794.
Oh, I did, but then I rewrote it and forgot to time both ways. I sort of
thought maybe this would be faster since the compiler can see the whole
thing easily, but it probably doesn't matter as the cost is mostly just
touching all the memory.

... it looks like VS has an SSE2 strchr path so let me check if I can
measure any difference.

On Thu, Oct 30, 2014 at 4:38 PM, Nico Weber <notifications@github.com>
wrote:

> In src/util.cc:
>
> > @@ -106,6 +106,12 @@ bool CanonicalizePath(char* path, size_t* len, string* err) {
> >      return false;
> >    }
> >
> > +#ifdef _WIN32
> > +  for (char* c = path; *c; ++c)
> > +    if (*c == '\\')
> > +      *c = '/';
>
> (out of interest, did you try the strchr-based loop i suggested? i
> suppose paths are short enough in practice that it doesn't matter?)
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/martine/ninja/pull/840/files#r19644068>.
>