On Jun 1, 2017 12:49 AM, "Paul Smith" <psm...@gnu.org> wrote:
This message is mainly for Eli but anyone else who uses GNU make on
Windows might have an opinion.
I'm working on ensuring that the test suite works on Windows (some of
that means disabling tests until someone has a chance to rework them to
be more portable, unfortunately :-/).
I came across a test failure in the backslash/newline tests on Windows
which I was curious about, and it lead me to this code in
read.c:readline():
#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.
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 don't think so. Without checking the code, I expect the reason behind not
doing this stuff on Windows is because Windows had two modes of file
access, binary and text and perhaps whoever wrote that code expected text
mode to be used when opening makefiles.
Text mode means that Windows converts CRLF to LF behind the scenes.
But, I didn't want to change this without asking if there might be a
reason for it that I'm missing.
_______________________________________________
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
_______________________________________________
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
