From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5581 invoked by alias); 22 Jan 2014 05:20:20 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 5571 invoked by uid 89); 22 Jan 2014 05:20:19 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-ie0-f181.google.com Received: from mail-ie0-f181.google.com (HELO mail-ie0-f181.google.com) (209.85.223.181) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Wed, 22 Jan 2014 05:20:18 +0000 Received: by mail-ie0-f181.google.com with SMTP id tq11so9292033ieb.12 for ; Tue, 21 Jan 2014 21:20:17 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=fYLg3iNrdeTwvVzeL6WZh/aggaMLQXoWTwbbcSMX5Fg=; b=D+uIIutMsphYCZ0/Gwba3obatbSaNMqizmB8W/yaEloFydSk4HJVlVQrMOSwsHMsit +MYF9AnRI4jb0uA9ze/Z0f+3StgquTkrzhyJmzQjrts/odongBE/bUiv31OPlZG96/qE r/QIbCKMXy6FVK2GwfwgsADMMvJbC7cwYDlvnf4VbwtJ87xKw5Jup+KK0bzynXeG/yZQ t93mX9kuA2vD07+uIAm7vkHGBMC80kMby3Xfr3ILrjwbu1mSzi7TDdcxMcAQJQfz6y5+ GaszIsCh9D/VkAhHPw1mAtSuQ170IoxJMur+jrPp7RevWhD6W/IRusA+n66+oxym56q7 MW6A== X-Gm-Message-State: ALoCoQnPNxVq5J+NP9ueDD14vksn7UsEicEd1BZnMEK4TEIit55P1Ztr7MkgG8Mz4gOwfZUTDaY9y6DMfT5GeCvlxSIFdxjqSkmMg1fSToKKPwzr/u1/YiHBsyTk4j6uTVeKd62C5FKIFSgKA2sfcg1ZZZa5cGjfBvqewNd1Szsm5ql9OBzDIfjRmgqwTESqbU+oE6+9a2D7kgT4eXuyCy64/1cAteAY9A== MIME-Version: 1.0 X-Received: by 10.43.161.2 with SMTP id me2mr22004803icc.20.1390368016990; Tue, 21 Jan 2014 21:20:16 -0800 (PST) Received: by 10.64.58.77 with HTTP; Tue, 21 Jan 2014 21:20:16 -0800 (PST) In-Reply-To: <20140122045956.GA4762@adacore.com> References: <20140118015244.GA22787@sourceware.org> <1390300575-6998-1-git-send-email-brobecker@adacore.com> <20140122045956.GA4762@adacore.com> Date: Wed, 22 Jan 2014 05:20:00 -0000 Message-ID: Subject: Re: [PATCH 1/2] Expand documentation of common-utils.h::FUNCTION_NAME From: Doug Evans To: Joel Brobecker Cc: gdb-patches Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2014-01/txt/msg00843.txt.bz2 On Tue, Jan 21, 2014 at 8:59 PM, Joel Brobecker wrote: >> > gdb/ChangeLog: >> > >> > * common/common-utils.h (FUNCTION_NAME): Expand the macro's >> > documentation a bit. >> > >> > I would commit on its own, but since I am going to put the next in >> > for the same macro up for review, it's just as easy to make that one >> > wait as well, in case there are comments. >> >> Yeah, I stumbled a bit on this myself. >> It's not clear to me whether not defining it or defining it as NULL >> (and update all current users to deal with that) is better but I went >> with keeping things as they are. > > I almost had the same thoughts. I agree that it's just best to let > things as they are until we have evidence that changing them would > be beneficial. The difference is that I was thinking of defining > FUNCTION_NAME to something like "" rather than NULL. > Without more evidence, not clear which would be best... Yeah. The argument against is that maybe sometime one would want to know if its unknown, and comparison with NULL is easier, more maintainable than strcmp (unless "" was a macro, but maybe that's overkill).