Re: bin/60921: m4 --undefine argument does not undefine

["Phil Hagelberg via gnats" <gnats-admin%NetBSD.org@localhost>]

The following reply was made to PR bin/60921; it has been noted by GNATS.

From: Phil Hagelberg <phil%hagelb.org@localhost>
To: "Michael van Elst via gnats" <gnats-admin%NetBSD.org@localhost>
Cc: netbsd-bugs%netbsd.org@localhost,  gnats-bugs%netbsd.org@localhost
Subject: Re: bin/60921: m4 --undefine argument does not undefine
Date: Sun, 25 Oct 2026 09:16:36 -0700

 "Michael van Elst via gnats" <gnats-admin%NetBSD.org@localhost> writes:
 
 >  For now, it doesn't make sense to request a GNU extension and then
 >  to undefine (or redefine) it. But with future multiple GNU extensions
 >  you may want to ask for them but also remove specific ones.
 
 I don't know what this means; I'm not really concerned with GNU. I am
 just basing this off the seemingly intended behavior described in the
 NetBSD man page for m4.
 
 Maybe I should back up. My real purpose for reporting this bug is that I
 wish to use m4 to process existing documents that have the word "shift"
 in them. Right now NetBSD's m4 treats that word as a macro even when it
 is clearly not being used as such. When I read the manual, I saw that it
 said I should be able to undefine it so that these documents could be
 processed normally, but that is not the case.
 
 Looking at it more closely, there may be more to the bug. The manual
 shows that `shift' is a built-in macro which is called using parens; the
 example shows:
 
   shift(arg1, ...)
 
 Most other macros which are documented as using parens will not be invoked
 when they are merely referred to by name. For example:
 
   echo len | m4 # prints "len"
 
 For some reason, the shift macro does not work that way; any unquoted
 use of the word "shift" will invoke the macro:
 
   echo shift this over | m4 # prints " this over"
 
 So if the --undefine feature worked, that could be used as a workaround
 to this problem. But it would be even better if that weren't necessary
 and the shift macro behaved like the other macros and was not invoked
 unless called using parens.
 
 The word "shift" is not particularly unlikely to be found in documents
 processed by m4; this behavior makes it very easy to invoke by accident.
 
 Would it be better to open a separate issue for this?