From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [217.70.183.195]) by sourceware.org (Postfix) with ESMTPS id B43633840C2D for ; Thu, 14 May 2020 08:35:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org B43633840C2D Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=seketeli.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=dodji@seketeli.org X-Originating-IP: 91.166.131.130 Received: from localhost (91-166-131-130.subs.proxad.net [91.166.131.130]) (Authenticated sender: dodj@seketeli.org) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id C539E60015; Thu, 14 May 2020 08:35:23 +0000 (UTC) Received: by localhost (Postfix, from userid 1001) id 3A8B01A4BFD; Thu, 14 May 2020 10:35:22 +0200 (CEST) From: Dodji Seketeli To: Matthias Maennich Cc: Giuliano Procida , libabigail@sourceware.org, kernel-team@android.com Subject: Re: [PATCH 0/3] Add an option to give finer-grained control of offset reporting. Organization: Me, myself and I References: <20200504162439.74028-1-gprocida@google.com> <20200512145120.GE131213@google.com> <86a72cca47.fsf@seketeli.org> <20200513193824.GD62716@google.com> X-Operating-System: Red Hat Enterprise Linux Server 7.7 X-URL: http://www.seketeli.net/~dodji Date: Thu, 14 May 2020 10:35:22 +0200 In-Reply-To: <20200513193824.GD62716@google.com> (Matthias Maennich's message of "Wed, 13 May 2020 21:38:24 +0200") Message-ID: <86k11ec3sl.fsf@seketeli.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-3.7 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libabigail@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Mailing list of the Libabigail project List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2020 08:35:27 -0000 Matthias Maennich a =C3=A9crit: [...] > I think I would like the one line of mention as I suggested. Omitting it > conditionally introduces more logic and likely we confuse users. Either way, we'll have to introdroce more logic anyway, so I am not concerned about that, if, of course that is useful. I guess what I wanted to say is that the one line mention seems like a good idea because that example is simple. If you have more than one non-contiguous addition/removal/changes of data members in the struct, then I am not sure the one liner mention is still that "relevant". Or maybe in that case we can avoir the one liner mention and emit the in-extenso message as we have today? What do you think? > I also do not see them as redundant, just obvious and therefore a > short form is enough to transmit this information. Hmmh, yes, I think you are right. The offset changes are not redundant per se. They just happen to be caused by the change, but they don't necessary have to be. Point taken. [...] >>Also, would it make sense to emit those qualified data member names when >>we are analyzying a C++ program? Or do you think it's more legible to >>emit always emit non-qualified data member names? > > I think this very much applies to C structs as well. In fact, the above > is a C example. Yeah, I got that. I really meant my question. I'll re-phrase it differently. Do you think we should avoid removing the full-qualification when we are analyzing c++ programs? Or do do you think what you are proposing for C should apply for C++ programs equally? I would think yes, but I am not sure. > I think we should use the non-qualified version if we > are in a nested block where the rest of the qualified name is already > emitted. In the above example, we are in the block of 'task_struct' > differences, hence we can strip that part away from > task_struct::in_ubsan'. This does make sense to me. If we agree that we should change this behaviour, then maybe we should create an enhance request for this. Shall we? Thanks, Cheers, --=20 Dodji