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