From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS22989 209.51.188.0/24 X-Spam-Status: No, score=-3.7 required=3.0 tests=AWL,BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id A91E51F910 for ; Thu, 3 Nov 2022 02:38:05 +0000 (UTC) Authentication-Results: dcvr.yhbt.net; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=clisp.org header.i=@clisp.org header.b="qUzdjCXm"; dkim-atps=neutral Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oqQ6n-0003Nv-9u; Wed, 02 Nov 2022 22:37:33 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oqQ6k-0003NG-CD for bug-gnulib@gnu.org; Wed, 02 Nov 2022 22:37:30 -0400 Received: from mo4-p00-ob.smtp.rzone.de ([81.169.146.216]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oqQ6i-0002ZJ-D9 for bug-gnulib@gnu.org; Wed, 02 Nov 2022 22:37:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1667443026; s=strato-dkim-0002; d=clisp.org; h=References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From:Cc:Date: From:Subject:Sender; bh=y7R/a2DRlHBNJ70dkhYlx2DgIAXMY2VFf2PhhMXw1Js=; b=qUzdjCXmw2A/aGql8ls6rIUFjeVbpwGZRCrdLcahn2UQVeraS4/92/3Uc3IM9VMZ4g 5uCMB5WQMPJC2upW/sNvq3jemHZxRri5qZk6c/4VY8Ha+8lyYPZlEIQukqdjrajt4E1z vJ6Zrd5gI7uLtocZSpwMJglHJO/QOHVhZ8sN9UsJQcgALR5l1iYWicDbCaIJTZUxVlmf 3oI+T4wqQC9EgWvjHbIlWwWRmvVgqIJTG8J54UbIemGjgZMavlLGZYA8GZX3B1+kLPfj +WLTHcsXkjDhMFpUeDrwQ2R4mn2hw4r+zWucQAmdcfq6QfivQo11ooHci5ZfS/q9pc3R ihkg== Authentication-Results: strato.com; dkim=none X-RZG-AUTH: ":Ln4Re0+Ic/6oZXR1YgKryK8brlshOcZlIWs+iCP5vnk6shH0WWb0LN8XZoH94zq68+3cfpOT1Pw4QjoHStsUIUzKskyV/f7Qsg==" X-RZG-CLASS-ID: mo00 Received: from nimes.localnet by smtp.strato.de (RZmta 48.2.1 AUTH) with ESMTPSA id v9c7e6yA32b5qn1 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate); Thu, 3 Nov 2022 03:37:05 +0100 (CET) From: Bruno Haible To: bug-gnulib@gnu.org, Paul Eggert Cc: Karl Berry , Florian Weimer Subject: Re: scratch_buffer.h, scratch_buffer_dupfree.c sync Date: Thu, 03 Nov 2022 03:37:05 +0100 Message-ID: <3611769.t68216eyJU@nimes> In-Reply-To: <37ceea2b-7140-74e5-7013-3dbfc4b0fe57@cs.ucla.edu> References: <202211022237.2A2Mb6uK000339@freefriends.org> <37ceea2b-7140-74e5-7013-3dbfc4b0fe57@cs.ucla.edu> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Received-SPF: none client-ip=81.169.146.216; envelope-from=bruno@clisp.org; helo=mo4-p00-ob.smtp.rzone.de X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_NONE=0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: bug-gnulib@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gnulib discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "bug-gnulib" Errors-To: bug-gnulib-bounces+normalperson=yhbt.net@gnu.org Paul Eggert wrote: > Yes, it's a nontrivial merge. However, I think we can still sync > LIBC/include/scratch_buffer.h. I installed the attached patch It's a backward-incompatible change: A documented function is now suddenly gone, without a deprecation period. Let me document it in NEWS. I think this has some consequences on how we deal with glibc internals in Gnulib. We exported the 'scratch_buffer' module, thinking that it's a welcome addition to the Gnulib API. But we are seeing that either the glibc people did not know that this API is exported from Gnulib, or they knew but ignored the fact that this API is exported from Gnulib. Could anything be done to avoid such things from occurring again? If not, then I'm inclined to view this way of exporting glibc internals as a failed experiment. And as a consequence, we should only take and export glibc code if it is - either a POSIX API, or - documented in the glibc manual. And if we have Gnulib modules that contain glibc-internal code, we should make it clear that it is not Gnulib public API. In other words, I'm suggesting to rename the modules scratch_buffer -> glibc-internal/scratch_buffer dynarray -> glibc-internal/dynarray 2022-11-02 Bruno Haible scratch_buffer: Document last change. * NEWS: Mention last change. diff --git a/NEWS b/NEWS index 840564703a..327fc8ceee 100644 --- a/NEWS +++ b/NEWS @@ -74,6 +74,8 @@ User visible incompatible changes Date Modules Changes +2022-11-02 scratch_buffer The function 'gl_scratch_buffer_dupfree' is removed. + 2022-09-10 stdbool This module now assumes C99 and provides C23, instead of providing C99. For the old behavior, use the already-deprecated stdbool-c99 module.