[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Incorrect parsing of DOS/Windows paths ??
From: |
Eli Zaretskii |
Subject: |
Re: Incorrect parsing of DOS/Windows paths ?? |
Date: |
Tue, 20 Dec 2016 18:32:06 +0200 |
> From: Paul Smith <address@hidden>
> Cc: address@hidden
> Date: Tue, 20 Dec 2016 00:31:50 -0500
>
> On Sun, 2016-12-18 at 22:10 +0200, Eli Zaretskii wrote:
> > > Maybe it would be clearer what the issue was if we removed the second
> > > colon:
> > >
> > > foo:/bar ; @echo hi
> > >
> > > In UNIX this would be "foo : /bar ; @echo hi" which is a valid rule.
> >
> > On Windows, this is ambiguous, i.e. it invokes "undefined behavior".
> > There's no reason for Make on Windows to second-guess that the user
> > meant "foo : /bar". (In practice, no one writes such rules, certainly
> > not on Windows.)
>
> Well, that's a perfectly valid makefile and the POSIX standard specifies
> exactly how it should be parsed. I can't see any reason why Windows
> should not following the standard in this case. It's simple for make to
> realize that "foo:/bar" is not a valid path on Windows and hence, it
> must be parsed as "foo : /bar".
>
> Now, if the rule was this:
>
> c:/bar ; @echo hi
>
> that would be a lot harder to recognize; in theory we could do so, since
> there's only one legal way to parse this.
What about this:
cc:/bar ; @echo hi
Is it better to emit an error or silently parse as cc : /bar ?
> > Well, one issue is that a target name doesn't have to be a valid file
> > name, right? Do we want to support such target names?
>
> It doesn't have to be a valid filename, no. But we still have to parse
> the line. In the absence of any particular reason (e.g., supporting
> drive letters when HAVE_DOS_PATHS is set) I'd prefer to have the parsing
> of the line behave the same on Windows and UNIX.
But it already doesn't behave the same. And if the target name
doesn't have to be a valid file name, then we cannot make decisions
based on its validity as a file name.
> > And I still feel we should have some kind of formal definition of what
> > constitutes a valid line parsed by that function. Leaving this to the
> > code to tell is less desirable, IMO.
>
> I can improve the comments for that function; unfortunately while it
> does explain a lot it doesn't mention the stopmap argument.
That'd be helpful, thanks.
> The behavior I propose to implement is that in the case where
> HAVE_DOS_PATHS is set, and where we can determine that we stopped at
> the second character in the current filename which is equal to ":", and
> the first character was [A-Za-z], and the third character is "\" or "/"
> (by your request), then we'll assume that this colon is actually part of
> the filename and we won't stop parsing the string, but instead we'll
> continue until the next valid stopping point; if that's another ":" in
> the string before the end of the current filename then we won't treat
> that one specially and will recognize it as a stop character.
I'm unconvinced wrt which alternative is better, and I don't think
anyone complained about that code since it was written. But you are
the Make maintainer, and you certainly know the codebase better than I
do. So I will yield to your opinions.
Thanks.