NetBSD Problem Report #49214

From  Thu Sep 18 08:03:02 2014
Return-Path: <>
Received: from ( [])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "", Issuer "Postmaster" (verified OK))
	by (Postfix) with ESMTPS id 66B50CE692
	for <>; Thu, 18 Sep 2014 08:03:02 +0000 (UTC)
Message-Id: <>
Date: Thu, 18 Sep 2014 08:03:02 +0000 (UTC)
Subject: make(1) parsing bug with dynamic sources
X-Send-Pr-Version: 3.95

>Number:         49214
>Category:       bin
>Synopsis:       make(1) parsing bug with dynamic sources
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    dholland
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Sep 18 08:05:00 +0000 2014
>Last-Modified:  Fri Nov 28 20:21:30 +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 amd64
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



Responsible-Changed-From-To: bin-bug-people->dholland
Responsible-Changed-When: Thu, 18 Sep 2014 08:19:45 +0000


NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD:,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2014 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.