NetBSD-Bugs archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: toolchain/53146
The following reply was made to PR toolchain/53146; it has been noted by GNATS.
From: Roland Illig <roland.illig%gmx.de@localhost>
To: gnats-bugs%NetBSD.org@localhost, Christos Zoulas <christos%netbsd.org@localhost>,
Simon Gerraty <sjg%crufty.net@localhost>
Cc:
Subject: Re: toolchain/53146
Date: Sun, 13 Mar 2022 22:10:15 +0100
Hi David,
https://gnats.netbsd.org/53146
Your interpretation of what happens inside make is completely accurate.
As of 2022-03-13, make allows all characters in the name of a .for
variable, see the implementation of ForLoop_ParseVarnames in
usr.bin/make/for.c.
This is an unfortunate situation, and the tests in
usr.bin/make/unit-tests do not yet cover all details of the current
behavior.
I suggest to forbid any variable expressions in the names of .for loop
variables, because, as you say, it seems like a wild thing to do. At
least in make's "strict mode" (-dL), it should complain, probably in
default mode as well.
A simple search for '^\.\s*for.*?\$.*?\bin\b' didn't find any matches in
pkgsrc. The same search in the NetBSD tree found a false positive in
heimdal/Makefile.rules.inc and the few test cases in
usr.bin/make/unit-tests. Based on these search results and the general
notion that using this feature in a productive way is a brain twister
anyway, I think that this "feature" is not used anywhere and that it can
be removed.
Roland
Home |
Main Index |
Thread Index |
Old Index