From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1825 invoked by alias); 12 Sep 2008 15:36:18 -0000 Received: (qmail 1814 invoked by uid 22791); 12 Sep 2008 15:36:17 -0000 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 12 Sep 2008 15:35:38 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id 5F48F1049C; Fri, 12 Sep 2008 15:35:36 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id 2C47E101C3; Fri, 12 Sep 2008 15:35:36 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.69) (envelope-from ) id 1KeAgI-0003bO-Vd; Fri, 12 Sep 2008 11:35:35 -0400 Date: Fri, 12 Sep 2008 15:36:00 -0000 From: Daniel Jacobowitz To: =?iso-8859-1?Q?Andr=E9_P=F6nitz?= Cc: gdb@sources.redhat.com Subject: Re: gdb sources Message-ID: <20080912153534.GA13672@caradoc.them.org> Mail-Followup-To: =?iso-8859-1?Q?Andr=E9_P=F6nitz?= , gdb@sources.redhat.com References: <200809121713.09226.apoenitz@trolltech.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <200809121713.09226.apoenitz@trolltech.com> User-Agent: Mutt/1.5.17 (2008-05-11) X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-09/txt/msg00072.txt.bz2 On Fri, Sep 12, 2008 at 05:12:50PM +0200, André Pönitz wrote: > In one branch, p points to a literal, in the other to the heap. > shell_escape() does not seem to release any memory (would > also be wrong in the literal case...), so if the else branch is > taken it's a leak, no? Yes, looks like a leak. > (2) Most of the "strings" in gdb are "char *", even if they are > conceptionally "const char *" (i.e. coming from literal, or not > intended to be changed). Why? In some places "const" is also > used, so the reason can't be "gdb supports compilers that > don't know about 'const'". Is it "just legacy"? If so, would patches > replacing "char *" by "const char *" if appropriate be welcome? Yes, constifying patches are welcome. It's just that gdb _used_ to support compilers that didn't know const, and may even predate const in places. > (3) Most of the declarations in command.h are repeated in > cli/cli-decode.h even though cli-decode.h #include's command.h. > Couldn't the duplicates just be removed? Probably; I don't know the history of it. -- Daniel Jacobowitz CodeSourcery