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.
https://github.com/martine/ninja/pull/841

On Thu, Oct 30, 2014 at 4:42 PM, Scott Graham <sgraham@gmail.com> wrote:

> 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>.
>>
>
>