From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 90808 invoked by alias); 26 Jun 2017 11:01:10 -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 90739 invoked by uid 89); 26 Jun 2017 11:01:09 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-11.9 required=5.0 tests=BAYES_00,GIT_PATCH_2,GIT_PATCH_3,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:1577 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 26 Jun 2017 11:01:08 +0000 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 5BFF061D0D for ; Mon, 26 Jun 2017 11:01:07 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 5BFF061D0D Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=palves@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 5BFF061D0D Received: from [127.0.0.1] (ovpn04.gateway.prod.ext.ams2.redhat.com [10.39.146.4]) by smtp.corp.redhat.com (Postfix) with ESMTP id B14AE7D67E; Mon, 26 Jun 2017 11:01:06 +0000 (UTC) Subject: Re: [PATCH] Compute proper length for dynamic types of TYPE_CODE_TYPEDEF To: Keith Seitz , gdb-patches@sourceware.org References: <1498265971-27536-1-git-send-email-keiths@redhat.com> From: Pedro Alves Message-ID: <8d848672-f348-08e6-f395-aa110cdc2f7d@redhat.com> Date: Mon, 26 Jun 2017 11:01:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <1498265971-27536-1-git-send-email-keiths@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2017-06/txt/msg00696.txt.bz2 Hi Keith, On 06/24/2017 01:59 AM, Keith Seitz wrote: > --- a/gdb/testsuite/gdb.base/vla-datatypes.c > +++ b/gdb/testsuite/gdb.base/vla-datatypes.c > @@ -46,11 +46,12 @@ vla_factory (int n) > BAR bar_vla[n]; > int i; > > - struct vla_struct > + typedef struct vla_struct > { > int something; > int vla_field[n]; > - } vla_struct_object; > + } vla_s; > + vla_s vla_struct_object; This object is now defined with a typedef type, and that confused me a lot. After staring at this for a while, I think you did intend that. I just find the naming very confusing. Can we improve on that? Maybe add some comments too. > > struct inner_vla_struct > { > @@ -59,14 +60,28 @@ vla_factory (int n) > int after; > } inner_vla_struct_object; > > + struct vla_typedef ... because this type is called "typedef", while the above isn't. > + { > + int something; > + vla_s vla_object; > + } vla_typedef_struct_object; ... and this object here is not a a type that is defined as a typedef, while it's named "..._typedef_...". So at first is looked like you have the "typedef vs non-typedef" cases backwards. I understand now that you're referring to the "vla_object" member, but it was totally non-obvious to me. Can we rename things a bit to avoid this confusion? Maybe struct vla_typedef -> struct vla_s_struct_member union vla_typedef_union -> union vla_s_union_member ? and add some comment about using "vla_s" throughout because it's a typedef. And/or rename it to "vla_struct_typedef". Thanks, Pedro Alves