From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27821 invoked by alias); 28 Jan 2007 07:57:21 -0000 Received: (qmail 27810 invoked by uid 22791); 28 Jan 2007 07:57:20 -0000 X-Spam-Check-By: sourceware.org Received: from zigzag.lvk.cs.msu.su (HELO zigzag.lvk.cs.msu.su) (158.250.17.23) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 28 Jan 2007 07:57:16 +0000 Received: from Debian-exim by zigzag.lvk.cs.msu.su with spam-scanned (Exim 4.50) id 1HB4uS-0005tu-Te for gdb-patches@sources.redhat.com; Sun, 28 Jan 2007 10:57:14 +0300 Received: from localhost ([127.0.0.1] helo=ip6-localhost) by zigzag.lvk.cs.msu.su with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1HB4uA-0005tB-7j; Sun, 28 Jan 2007 10:56:50 +0300 From: Vladimir Prus To: Nick Roberts Subject: Re: -var-info-path-expression Date: Sun, 28 Jan 2007 07:57:00 -0000 User-Agent: KMail/1.9.1 Cc: Daniel Jacobowitz , gdb-patches@sources.redhat.com References: <200612251200.42622.ghost@cs.msu.su> <200701280048.37153.ghost@cs.msu.su> <17851.62039.333484.886195@kahikatea.snap.net.nz> In-Reply-To: <17851.62039.333484.886195@kahikatea.snap.net.nz> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200701281056.31488.ghost@cs.msu.su> 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: 2007-01/txt/msg00564.txt.bz2 On Sunday 28 January 2007 03:46, Nick Roberts wrote: > > c_describe_child (struct varobj *parent, int index, > > - char **cname, struct value **cvalue, struct type **ctype) > > + char **cname, struct value **cvalue, struct type **ctype, > > + char **cfull_expression) > > This argument list gets longer but, apart from only parent and index, only > one argument is non-null at any one time. A future patch is very likely to change this. In particular, the 'create_child' function needs both name of the child and its value. I might kill separate function pointers in struct language_specific and use just single describe_child and make create_child pass two non-NULL pointers? > Would it be better to have > > enum varobj_child_properties > { > CHILD_NAME, > CHILD_VALUE, > CHILD_TYPE, > CHILD_FULL_EXPRESSION > } > > static void * > c_describe_child (enum varobj_child_properties property, > struct varobj *parent, int index) > > and propagate these changes back to struct language_specific so we have: > > static char * > name_of_child (struct varobj *var, int index) > { > return (char *) (*var->root->lang->describe_child) (CHILD_NAME, var, index); And have casts from void* to the right type? I'm not sure that's any advantage. - Volodya