Subject: Re: make: Dir_FindFile still broken
To: Simon J. Gerraty <>
From: Christos Zoulas <>
List: tech-toolchain
Date: 11/13/2002 23:07:31
On Nov 13,  5:37pm, ("Simon J. Gerraty") wrote:
-- Subject: Re: make: Dir_FindFile still broken

| Yes, but all this lookup code currently special cases '.' and 
| paths that start with '/', paths that start with '../' are really 
| not handled correctly at all.

It is dangerous because in the absense of the second stat call, the path
might be referencing a different file.

| >that the two paths resolve to the same file, and that will require
| >2 stats(). One way is to use size_t len = strlen(path); strncmp(path,
| >file, len) && file[len] == '/' but that does not feel right. Another
| That (absent the last check for '/') is what I'm doing, adding the check for 
| '/' is a good idea.  In the case of a hit there is no 2nd stat call 
| the goto skips by it ;-)
| >way is to parse the /../ and collapse them. Again this is ucky and
| >does not work in all cases.
| And would defeat the purpose of putting a relative path in .PATH.

No, it would not; it would only collapse /../ inside the path string; not
leading ones. The problem is again that without a stat, due to symbolic
links, it would reference different files.

| The only other thing I can think of is a new magic token .ASIS or something
| Then you could have:
| but I think the path is a prefix of name and stat check is reasonable.
| The ugly bit is the goto - but the alternative is an extra stat(2) which
| I'd like to avoid.  Ie. we'd have:

The .ASIS is too much magic. I think we need to rethink and simplify the
logic instead of making it more complicated.