From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 88B0B3858D20; Fri, 11 Nov 2022 13:51:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 88B0B3858D20 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark.ca Received: from [10.0.0.11] (unknown [217.28.27.60]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 0F2971E0CB; Fri, 11 Nov 2022 08:51:22 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1668174683; bh=rAyA6DiWzCwvsd+EW9yMZ012h9ZfdaPxvUU9Afdzm1Y=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=Fn7cAT43BL/viAELiDzwmRmPiFJ0aFEX6woAarWnwASjO6SD9Y5cTArLfQIm+/GI9 rQ7fcKGCcJOdVEMXqFYkemJztR7hsSJhu78oy/0s4F+dqkK/oVM98AwwBfBsMALq3c JjDaWnsuPxREMCiEcF/qw7H2dVDjWLY4J6nJfP28= Message-ID: Date: Fri, 11 Nov 2022 08:51:21 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.1 Subject: Re: [PATCH] gdb: use libtool in GDB_AC_CHECK_BFD Content-Language: en-US To: Nix , Simon Marchi via Gdb-patches Cc: "Jose E. Marchesi" , Tom Tromey , indu.bhagat@oracle.com, elena.zannoni@oracle.com, binutils@sourceware.org References: <20221107194634.1313150-1-jose.marchesi@oracle.com> <5e940b15-cd5c-83b2-0bdd-9afa27b5f197@simark.ca> <87bkpeuae6.fsf@oracle.com> <875yfmztd6.fsf@tromey.com> <87sfiqsr7m.fsf@oracle.com> <87sfiqwx82.fsf@esperi.org.uk> <08a946a3-904f-0948-35af-96f77d2e008c@simark.ca> <87iljlwrze.fsf@esperi.org.uk> From: Simon Marchi In-Reply-To: <87iljlwrze.fsf@esperi.org.uk> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: > It's historical (it was there in the Solaris days, IIRC) and alas it has > users, and it has a use case (see below). We *could* rip it out and fix > the users, but that does mean breaking the API and bumping soname and > this seems like a rather petty reason to do so to me. (But then I know > I'm a stable-API fetishist.) > >> Imagine you wanted to >> switch to another gz compression library without changing your API. It >> would be nicer if zlib was just an implementation detail here. For >> instance, you could take a plain fd and use gzdopen internally to open a >> gzFile around it. > > I think the intent here was that people who were already writing stuff > through a gzFile could pass it into this to write CTF in as well. That > doesn't work at all well if you pass in the underlying fd and do a > gzdopen (you end up with zlib thinking there are two gzip streams > underway simultaneously on the same fd, and a total mess results). > > So really you'd need *both* :) > > > But really this whole class of API made more sense back in the past when > zlib was the only compression library worth speaking of. These days > you'd probably prefer to hand back the memory buffer and ask the caller > to do the compression themselves using whatever mechanism they prefer -- > but the fact remains that this thing is in the API and I'd rather not > break it for such a minor reason if there is a non-totally-horrible > alternative. Thanks for the details. Another idea I thought of, which would still break the API (in that callers would need to include a new source file) but not the ABI would be to put that declaration in a separate header, say ctf-gzip-api.h. Users of ctf-api.h would not have to deal with zlib. Users of ctf-gzip-api.h would have to deal with zlib, but that's fine because they are consciously using it. Simon