Re: Incorrect parsing of DOS/Windows paths ??

[Eli Zaretskii]

> 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.