Re: Q: On Windows why not ignore CRLF?

[thutt]

Eli Zaretskii writes:
 > > From: Paul Smith <address@hidden>
 > > Date: Wed, 31 May 2017 19:48:57 -0400
 > >
 > > I'm working on ensuring that the test suite works on Windows
 >
 > That's great news, thanks!
 >
 > >   #if !defined(WINDOWS32) && !defined(__MSDOS__) && !defined(__EMX__)
 > >         /* Check to see if the line was really ended with CRLF; if so 
 > > ignore
 > >            the CR.  */
 > >         if ((p - start) > 1 && p[-2] == '\r')
 > >           {
 > >             --p;
 > >             memmove (p-1, p, strlen (p) + 1);
 > >           }
 > >   #endif
 > >
 > > I'm not sure about this implementation (performance-wise) but leaving
 > > that aside, I don't understand why this code is ifdef'd out on Windows.
 >
 > Well, it's your code, or so it seems ;-)  And it was always ifdef'ed
 > away on those platforms, since the day it was committed back in 1999
 > (see commit 7052a57).
 >
 > > I mean, CRLF is more prevalent on Windows so why wouldn't we have this
 > > there?
 > >
 > > Is the idea that on Windows we want to preserve the CRLF, for some
 > > reason?  I'm not sure I see the point in doing that when we're parsing
 > > the makefile; I mean we'd throw away all the newlines on UNIX, so why
 > > would we preserve the CRLF on Windows?
 >
 > I think Ray is right: the CRLF combination simply cannot happen on
 > those platforms, because Make there uses text-mode reads, so the CR
 > characters are simply gone by the time we get here.

 I concur that the code is disabled on Windows due to text mode
 stripping away the '\r' and leaving only '\n' in the input stream.

 I surmise it's enabled on non-Windows builds to allow them to work
 wtih Makefiles created on a Windows machine.

thutt
--
What books will be in the Trump Presidential Library?