From owner-freebsd-bugs@FreeBSD.ORG Tue Apr 27 22:00:40 2004 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0EEB416A4D3 for ; Tue, 27 Apr 2004 22:00:40 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id E94A343D53 for ; Tue, 27 Apr 2004 22:00:37 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) i3S50bmu099252 for ; Tue, 27 Apr 2004 22:00:37 -0700 (PDT) (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.11/8.12.11/Submit) id i3S50bIu099251; Tue, 27 Apr 2004 22:00:37 -0700 (PDT) (envelope-from gnats) Date: Tue, 27 Apr 2004 22:00:37 -0700 (PDT) Message-Id: <200404280500.i3S50bIu099251@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org From: Craig Boston Subject: Re: bin/59883: divert cannot be renamed in FreeBSD m4 [with patch] X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Craig Boston List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2004 05:00:40 -0000 The following reply was made to PR bin/59883; it has been noted by GNATS. From: Craig Boston To: freebsd-gnats-submit@FreeBSD.org, bremner@unb.ca Cc: Subject: Re: bin/59883: divert cannot be renamed in FreeBSD m4 [with patch] Date: Tue, 27 Apr 2004 23:50:34 -0500 --Boundary-00=_agzjAbC17iIIQlN Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, I've recently run into the same problem with our m4 -- defn() appears to not work correctly with builtins, so they cannot be copied/renamed at all. The problem seems to be the result of a commit from about 2 years (!) ago. Guess nobody uses BSD m4 very much :) http://www.freebsd.org/cgi/cvsweb.cgi/src/usr.bin/m4/main.c?rev=1.14&content-type=text/x-cvsweb-markup p->defn = null; was changed to p->defn = xstrdup(null); as part of a GCC3 const/WARNS sweep. null is apparently a pointer to a somewhat "magic" empty string. The problem happens in dodefn() in eval.c when this is checked: if (p->defn != null) { [ do stuff for macros ] } else ... { [ do stuff for builtins ] } p->defn is no longer == to null for builtins, but rather a copy of it. I changed it to instead check p->type to see if it's a macro or not and that seems to fix it. Also checked the OpenBSD CVS and it looks like they fixed the problem there with a very similar (though more extensive) approach. A quick grep/once-over of the code didn't turn up any more (ab)use of pointers to "null" that would be affected by this. Patch is both inline (tabs mangled I'm sure) and attached -- I don't remember if gnats accepts MIME attachments :-/ --- eval.c.orig Tue Apr 27 23:33:03 2004 +++ eval.c Tue Apr 27 23:33:57 2004 @@ -617,7 +617,7 @@ const char *real; if ((p = lookup(name)) != nil) { - if (p->defn != null) { + if ((p->type & TYPEMASK) == MACRTYPE) { pbstr(rquote); pbstr(p->defn); pbstr(lquote); --Boundary-00=_agzjAbC17iIIQlN Content-Type: text/plain; charset="us-ascii"; name="bsd.m4.defn.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="bsd.m4.defn.patch" --- eval.c.orig Tue Apr 27 23:33:03 2004 +++ eval.c Tue Apr 27 23:33:57 2004 @@ -617,7 +617,7 @@ const char *real; if ((p = lookup(name)) != nil) { - if (p->defn != null) { + if ((p->type & TYPEMASK) == MACRTYPE) { pbstr(rquote); pbstr(p->defn); pbstr(lquote); --Boundary-00=_agzjAbC17iIIQlN--