From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:39120) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S734b-0007dY-0n for qemu-devel@nongnu.org; Mon, 12 Mar 2012 07:05:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S734U-0000Bv-Mu for qemu-devel@nongnu.org; Mon, 12 Mar 2012 07:05:52 -0400 Received: from mx1.redhat.com ([209.132.183.28]:1028) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S734U-0000Bf-Ex for qemu-devel@nongnu.org; Mon, 12 Mar 2012 07:05:46 -0400 Message-ID: <4F5DD95B.10306@redhat.com> Date: Mon, 12 Mar 2012 12:09:15 +0100 From: Kevin Wolf MIME-Version: 1.0 References: <1331544868-31655-1-git-send-email-kwolf@redhat.com> <1331544868-31655-2-git-send-email-kwolf@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 2/2] tracetool: Forbid argument name 'next' List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: qemu-devel@nongnu.org Am 12.03.2012 12:01, schrieb Stefan Hajnoczi: > On Mon, Mar 12, 2012 at 9:34 AM, Kevin Wolf wrote: >> It has happened more than once that patches that look perfectly sane >> and work with simpletrace broke systemtap because they use 'next' as an >> argument name for a tracing function. However, 'next' is a keyword for >> systemtap, so we shouldn't use it. >> >> Signed-off-by: Kevin Wolf >> --- >> scripts/tracetool | 4 ++++ >> 1 files changed, 4 insertions(+), 0 deletions(-) >> >> diff --git a/scripts/tracetool b/scripts/tracetool >> index 4c9951d..f892af4 100755 >> --- a/scripts/tracetool >> +++ b/scripts/tracetool >> @@ -81,6 +81,10 @@ get_args() >> args=${1#*\(} >> args=${args%%\)*} >> echo "$args" >> + >> + if (echo "$args" | grep "[ *]next\($\|[, ]\)" > /dev/null 2>&1); then >> + echo -e "\n#error 'next' is a bad argument name (clash with systemtap keyword)\n " >> + fi > > Good idea, let's prevent it from being used. > > I don't think this is the way to do it because callers will parse > stdout and we're not guaranteed to be generating C code where #error > works. Instead, we can echo to stderr and do exit 1. Yes, we may generate something else additionally. But trace.h is generated in any case and it will cause a compile error before any non-C file is used. I tried the 'exit 1' approach first and it doesn't really work. This function is called from a subshell, so you don't exit tracetool but just the one subshell and end up with a broken trace.h that will fail compilation in the same place, just with a less helpful error message. Kevin