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: