From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from relay7-d.mail.gandi.net (relay7-d.mail.gandi.net [217.70.183.200]) by sourceware.org (Postfix) with ESMTPS id 074633858422 for ; Tue, 16 Aug 2022 16:54:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 074633858422 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=seketeli.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=seketeli.org Received: (Authenticated sender: dodji@seketeli.org) by mail.gandi.net (Postfix) with ESMTPSA id 29A5520009; Tue, 16 Aug 2022 16:54:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=seketeli.org; s=gm1; t=1660668847; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=4adG3wcKG1Fdg5/tGGqtThnxXfMr6qKkSLku2CZ9eRg=; b=k83YVN7XQSvOo04wXLsEoq5TEJ84YnujRiJSF1JmhXoqCLPppeN78+CX2r5SlXVSEDOnx4 ZBHRbYQNBDoDFkLo7Txtbvu62GSibkdybAMmfyXkSCBmvOrzhJQMsfH9F7AryBWmo5c/OJ ugkldW+Moy6+OhDmlUgQWRaJV2fHK3tCuxNX4Y+rgYz1x2bP4GI/tCldJ7srWErZh0yVMi CAli2n6XuqleNnuRLnLPjgTAR5wdTwdMrmlfNhnZxzlBmOe6bTnhQJ/j1+MiefGQKWOQTB n+KtWPIFfDlsXJ4P8GzeGbesOqOlCkd0l/d3zLoviMj3RII5ptblXfCmspOgaA== Received: by localhost (Postfix, from userid 1000) id 6EF135802BD; Tue, 16 Aug 2022 18:54:06 +0200 (CEST) From: Dodji Seketeli To: Giuliano Procida Cc: Dodji Seketeli , Dodji Seketeli via Libabigail , Matthias =?utf-8?Q?M=C3=A4nnich?= Subject: Re: [PATCH 3/3] ir: Consider integral types of same kind and size as equivalent Organization: Red Hat / France References: <87sfms91n0.fsf@redhat.com> <87czdw910h.fsf@seketeli.org> X-Operating-System: Fedora 38 X-URL: http://www.redhat.com Date: Tue, 16 Aug 2022 18:54:05 +0200 In-Reply-To: (Giuliano Procida's message of "Wed, 10 Aug 2022 16:23:59 +0100") Message-ID: <87edxgm8nm.fsf@redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-3.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, JMQ_SPF_NEUTRAL, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) 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: Tue, 16 Aug 2022 16:54:11 -0000 Giuliano Procida writes: > Hi Dodji. Hello Giuliano, [...] > On Sat, 23 Jul 2022 at 00:33, Dodji Seketeli wrote: >> >> Hello, >> >> On some platforms, "long int" and "long long int" can have the same >> size. In that case, we want those two types to be equivalent from ABI >> standpoint. Otherwise, through the use of typedefs and pointers, two >> structs "C" defined in different translation units where one uses >> "long int" in a translation unit and "long long int" in another should >> be considered ABI compatible if long int and long long int have the >> same size on that platform. > > While such types may be ABI compatible, they are not API compatible as they > impact (at least) C++ overload resolution. Right. But as usual with these things (API vs ABI conformance), we try to accommodate people's need as much as possible, with a preference with ABI conformance when we can't ensure both at the same time. That's what we have done historically, but of course, my stance is not cast in stone. I am open to discussion and change. In this particular case of /C type/ program, it seems to be that the programmers expect the types to be ABI compatible. C++ of course being strongly type as it is, I understand that we might want to be stricter. > All of char, unsigned char, signed char, int, unsigned, long, etc. are > distinct types. > Conflating some subsets of these will result in confusing ABI > difference reports. For C++ (or Ada, or in those strongly type languages) I think I understand why some change reports might be confusing. In your mind, can we have the issue with C however? (real question). >> Otherwise, that causes spurious type changes that lead to self >> comparison change down the road. For instance, the following command >> fails: >> >> $ tools/fedabipkgdiff --debug --self-compare -a --from fc36 btrfs-progs > > Shouldn't any tweaking of behaviour happen with abidiff rather than abidw? I am not sure to understand the question. This kind of adjustment of what is is read from the binary typically tends to happen at the core level (either DWARF reader, IR construction/transformation, comparison, etc) rather at the level of a specific tool. Am I missing something from what you have in mind? > > We might not end up with stable XML but the finger of blame should be > pointed at the btrfs-progs in any case. I understand and I sympathesize with your point of view. But just to explain where I sit on the matter, there have unfortunately been plenty of real life cases where the programs (those written by the app/library developers or by the compiler/linker developers) are not what libabigail would expect in a perfect world. So far we try hard to "accommodate" when we can, if that can lead to a better experience for libabigail users. But I agree that we shouldn't try harder. I guess knowing the difference is the crux of this art. So I am open to discussion to try to accommodate your point of view too. >> This patch thus changes the comparison engine of the IR so that the >> "short, long and long long" modifiers don't change the result of >> comparing integral types that share the same base type when they have >> the same size. > > We don't want this behaviour and can carry a revert patch in AOSP or > work a way to disable it that is less likely to cause merge conflicts > in the future. Would it be useful for your case if this behaviour happens just for C programs? > Is there an easy way of putting this under flag control? I guess so, yes. But just a flag would not be optimal from a user standpoint, would it? Thank you for raising this and sorry for the inconvenience. I hope we resolve this. Cheers, -- Dodji