From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20921 invoked by alias); 13 Mar 2008 19:22:25 -0000 Received: (qmail 20913 invoked by uid 22791); 13 Mar 2008 19:22:24 -0000 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 13 Mar 2008 19:22:02 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 448472AAB5F for ; Thu, 13 Mar 2008 15:22:00 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id NP3huodXlxXl for ; Thu, 13 Mar 2008 15:22:00 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 058102AA7FE for ; Thu, 13 Mar 2008 15:22:00 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id BF027E7ACB; Thu, 13 Mar 2008 12:21:57 -0700 (PDT) Date: Thu, 13 Mar 2008 19:22:00 -0000 From: Joel Brobecker To: gdb-patches@sourceware.org Subject: Re: [RFC] Strings and arrays without malloc Message-ID: <20080313192157.GJ3738@adacore.com> References: <20080309161335.GA26917@caradoc.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080309161335.GA26917@caradoc.them.org> User-Agent: Mutt/1.4.2.2i 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 X-SW-Source: 2008-03/txt/msg00153.txt.bz2 > Here's some things which call malloc today, and do not with the patch > applied - yes, even the sizeof and ptype ones: Woohoo! :) > Here's some expressions which used to call malloc and still do; these > are operations which involve pointers, so we need to call malloc to > get a valid pointer for them. > > print *"abc" > print "abc" + 1 > print &"abc" > print strcmp ("abc", "def") > print &{4, 5, 6} Honestly, except maybe for the case where strcmp is involved, I find that the semantics of the expressions could be debated. But you were able to preserve the previous behavior, which is great. > Here's some expressions which used to call malloc and will now produce > an error about "value not located in memory": > > print &{4, 5, 6}[1] > ptype &{4, 5, 6}[1] As per the above, I personally am not really all that much concerned about this kind of limitation, and I agree that subscripting is more interesting than getting the address of a subscripted element. It's still possible to get the answer by doing a sequence of commands instead of one convenient expression, but the following should work, right? print &{4, 5, 6} print &(*$)[1] Or, in one expression (if I get my precedence right): print &(*&{4, 5, 6})[1] Perhaps we could add this to the documentation too. I haven't looked at the code itself, but the benefits are really exciting IMO. -- Joel