Subject: bin/5811: m4 and dumpdef/defn
To: None <gnats-bugs@gnats.netbsd.org>
From: None <bgrayson@ece.utexas.edu>
List: netbsd-bugs
Date: 07/21/1998 13:20:29
>Number:         5811
>Category:       bin
>Synopsis:       dumpdef/defn don't seem to work with our m4
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    bin-bug-people (Utility Bug People)
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Jul 21 11:35:01 1998
>Last-Modified:
>Originator:     Brian Grayson
>Organization:
	Parallel and Distributed Systems
	Electrical and Computer Engineering
	The University of Texas at Austin
>Release:        July 20
>Environment:
	<Use :.!uname -a to embed this>

>Description:
	Using m4, I am trying to rename the internal macro
	include to be INCLUDE.  Under GNU m4, and according to
	our m4's man pages, the following should do the trick:
define(INCLUDE,defn(`include'))
define(include,`include')

dumpdef(include,INCLUDE)
#  With GNU m4, notice that the definitions are the way we want.
#  They aren't correct using our m4.
INCLUDE(<filename here>)
#  This works only with GNU m4.
include some text here
#  This properly prints `include some text here', as include is
#  no longer a keyword.

	When running our m4, it doesn't work at all.  What's also
	curious is that dumpdef prints `' for the definitions.
	Shouldn't it print <include> for include, or something,
	like GNU m4?
>How-To-Repeat:
	
>Fix:
	
	Don't know.  Tried looking at the code, but it appears
	that all builtin-macros have their defn pointer set to
	null in initkwds(), which makes it pretty hard for
	dumpdef and defn to return anything useful.  I'd guess
	that some special code would need to be added to notice
	the difference between a builtin-defn, a null defn, and
	an ordinary text defn.

	Are there good reasons to maintain our own instead of
	using the GNU one?  :(
>Audit-Trail:
>Unformatted: