make-w32
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Make CVS HEAD version build out of the box


From: Eli Zaretskii
Subject: Re: Make CVS HEAD version build out of the box
Date: Mon, 01 Oct 2007 22:34:30 +0200

> From: "grischka" <address@hidden>
> Date: Mon, 1 Oct 2007 20:37:56 +0200
> 
> > Well, obviously casting a const char* to a char* so you can modify it is
> > not valid code.  There's a reason these values are const, and that
> > reason is that they should not be modified.
> 
> Well, that is maybe arguable whether or not a cast is valid code in C.

It's valid C, allright, but the code clearly wants not to modify the
`name' argument to the function, and the function's prototype promises
that it won't be modified.  So modifying it would be a breach of
contract between the function and its callers.  If, for example, at
some point, `find_directory' is passed a constant string literal as
its argument, Make could crash at run time.

I will suggest an alternative patch in a while.

> However I wonder what problem the original hack is trying to solve 
> at all.

There's a comment there that says it all:

      /* Remove any trailing '\'.  Windows32 stat fails even on valid
         directories if they end in '\'. */

And I can confirm that this is true: `stat' fails on Windows if its
argument ends in a slash or a backslash.

> Or, what now is a practical case where a gmake with that 
> hack works better than one without?

I don't know how to come up with an example that shows this problem.
But we don't need a specific example to know that this is a problem
that needs to be taken care of.  Good engineering does not need an
example for each potential problem in order to prevent them.  As long
as we cannot prove that the argument will _never_ have a trailing
slash, we need to protect against that.

> For example, the linux version of gmake considers 'dir' and 
> 'dir/' as well as './dir/' all the same, and removes any 
> 'decoration' automatically:

That's a feature of a Posix filesystem.  It doesn't work that way on
Windows.

> $ gmake
> mkdir dir
> $ gmake
> mkdir dir/
> Invalid option - /

That's because `mkdir' that got invoked is the built-in command of the
Windows shell, and that built-in command thinks a forward slash begins
an option.  Try quoting the directory name, like this:

   mkdir "dir/"

then I think it will work, because the slashes inside quotes aren't
interpreted by the Windows shell.

But this has nothing to do with the problem at hand: the code we are
talking about calls `stat' on directories, AFAIK as part of Make's
directory-caching machinery.

> So, there is still the question: when is the backslash trick in 
> find_directory supposed to help, actually?

Whenever the argument has a trailing slash.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]