NetBSD-Bugs archive

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

bin/49214: make(1) parsing bug with dynamic sources

>Number:         49214
>Category:       bin
>Synopsis:       make(1) parsing bug with dynamic sources
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    bin-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Sep 18 08:05:00 +0000 2014
>Originator:     David A. Holland
>Release:        NetBSD 7.99.1 (20140918)
System: NetBSD 6.1_STABLE NetBSD 6.1_STABLE (NBMAIL) #0: 
Tue Jun 10 18:49:40 UTC 2014
Architecture: x86_64
Machine: amd64

Observe the following:

% cat woops
blah: ;
foo: $(.TARGET:S/foo/mo oo/)
        echo $(.ALLSRC)
bar $(.TARGET:S/foo/mo oo/): blah
        echo $(.ALLSRC)
% make -f woops foo
make: Unclosed substitution for @ (/ missing)
make: don't know how to make oo/). Stop

make: stopped in [dir]
% make -f woops bar
echo blah

The space inside the variable is only parsed correctly when the
variable is on the target side of the rule.

But there's a second problem: what does it even mean for $(.TARGET) to
be used on the target side of the rule? It's not sensible and produces
odd behavior. The unexpanded variable string becomes itself a rule
name, and then trying to use $(.TARGET) blows up because it's self-

% cat woops2
foo $(.TARGET:S/foo/moo/): blah
        echo $(.ALLSRC)
bar $(.TARGET:S/bar/baz/): blah
        echo $(.TARGET)

% make -f woops2 '$(.TARGET:S/foo/moo/)'
echo blah
% make -f woops2 '$(.TARGET:S/bar/baz/)'
Variable @ is recursive.

make: stopped in [dir]

This situation arises because $(.TARGET) and a handful of other rules
are allowed to be expanded dynamically in the sources list for each
target in a rule; therefore they're expanded late and not during the
main parsing pass.

However, it seems that someone accidentally added the code to
recognize them and call Var_Parse on them to properly find the end of
the variable reference to the targets half of the dependency rule
parser in ParseDoDependency instead of the source half. (This is
entirely understandable as the code's quite a maze.)

They aren't valid at all as targets and should be rejected if found on
the targets side.

A passing note that a problem might exist appeared in the PR 49085
patch from Jarmo Jaakkola, although this issue is otherwise unrelated
to that PR.

as above

move the logic as needed

Home | Main Index | Thread Index | Old Index