From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 104569 invoked by alias); 11 Dec 2017 22:50:46 -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 104558 invoked by uid 89); 11 Dec 2017 22:50:46 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 spammy=worthless 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, 11 Dec 2017 22:50:45 +0000 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 42F6E4ACAC; Mon, 11 Dec 2017 22:50:44 +0000 (UTC) Received: from localhost (unused-10-15-17-193.yyz.redhat.com [10.15.17.193]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 1B55F60621; Mon, 11 Dec 2017 22:50:44 +0000 (UTC) From: Sergio Durigan Junior To: Pedro Alves Cc: Simon Marchi , GDB Patches , Tom Tromey , Eli Zaretskii Subject: Re: [PATCH v2] Implement pahole-like 'ptype /o' option References: <20171121160709.23248-1-sergiodj@redhat.com> <20171128212137.15655-1-sergiodj@redhat.com> <87o9n5drbn.fsf@redhat.com> <99286acb-ce9f-42f0-41c3-ef10e03171ff@ericsson.com> <87tvwxc6t9.fsf@redhat.com> <964bae42-6e60-4e9d-048c-ef570c1d3a5b@redhat.com> Date: Mon, 11 Dec 2017 22:50:00 -0000 In-Reply-To: <964bae42-6e60-4e9d-048c-ef570c1d3a5b@redhat.com> (Pedro Alves's message of "Mon, 11 Dec 2017 22:42:22 +0000") Message-ID: <87fu8gdgl8.fsf@redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-SW-Source: 2017-12/txt/msg00253.txt.bz2 On Monday, December 11 2017, Pedro Alves wrote: > On 12/11/2017 09:07 PM, Sergio Durigan Junior wrote: > >>>> This is actually on purpose. If I indent the line, it will have more >>>> than 80 chars. I believe this is a well known method for avoiding this >>>> problem...? >>> >>> I am not aware of that. In this case I would put the parameter list on the next, >>> I'm not sure if it's 100% GNU-style approved, but nobody complained when I did it >>> so far :) >>> >>> static void >>> print_spaces_filtered_with_print_options >>> (int level, struct ui_file *stream, const struct type_print_options *flags); >>> >>> It helps with long function names. In this case, I would probably just drop the >>> "struct" to save a few chars, because C++. >> >> Fair enough. I use this trick for function prototypes, but not for the >> definitions. > > Simon's format is what I've been using for a long while too. Well, I could post a few examples of the format I chose, but I'm pretty sure this would be worthless. As I said, I will change my code. >>> But I don't mind it, it just stuck out as a little inconsistency. >> >> I don't see the inconsistency. >> >> If a field is inside a struct, it has its offset *and* size printed. No >> matter if the field is an int, another struct, or an union. >> >> If a field is inside an union, it has only its size printed. >> >> In the case above, it makes sense to have the offsets printed for the >> fields inside the two structs (inside the union), because there might be >> holes to report (well, one can argue that it doesn't matter if there are >> holes or not in this case, because if the other struct is bigger then >> the union size will stay the same). However, it doesn't make sense to >> print the offsets for the two structs themselves, because they are >> members of the union. >> >> I hope it makes more sense now. > > But why do we need the special case? Does it help anything? > So far, it seems it only added confusion. What do you mean by "special case"? This is what pahole does, and as I've said a few times, the output of 'ptype /o' has been based on pahole's output. I don't consider this a special case; I consider it to be the natural thing to do, because offsets don't make much sense in unions. > The option is "/o" for "print offsets". Why not print offsets always? I hope I explained it above. > BTW, shouldn't the documentation in the manual include an example > of GDB's output? I can include an example, OK. -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible http://sergiodj.net/