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=-4.4 required=3.0 tests=AWL,BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI,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 6CEE71F910 for ; Thu, 3 Nov 2022 19:37:35 +0000 (UTC) Authentication-Results: dcvr.yhbt.net; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.b="JyC7u9ZZ"; dkim-atps=neutral Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oqg1g-0003IG-Jo; Thu, 03 Nov 2022 15:37:20 -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 1oqg1f-0003Fz-Ir for bug-gnulib@gnu.org; Thu, 03 Nov 2022 15:37:19 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oqg1c-00070b-LP for bug-gnulib@gnu.org; Thu, 03 Nov 2022 15:37:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1667504235; 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=PxBSXsbK850kEZRu1XfOCMddgF2kPJIB+6Xxem8vm0o=; b=JyC7u9ZZzEm0UBNrqrT5Od+jaOISn0irySJU3xyKooJljcoAMYz/JVes0IcC9Jd5L2xVfE igk1LOvwc5p9f+22F5/nY3Q8qRBY4K60DTQseu1aJBreeu5a+7oRYk4q/KkVOYUForB+au SUrxiYYlTUZ+yeeXJbdWEODec1IzGCI= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-498-Mz_nN5BvNyWaCRiqk_IVlw-1; Thu, 03 Nov 2022 15:37:11 -0400 X-MC-Unique: Mz_nN5BvNyWaCRiqk_IVlw-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 52C9C2823807; Thu, 3 Nov 2022 19:37:11 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.2.16.64]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 662487AE5; Thu, 3 Nov 2022 19:37:10 +0000 (UTC) From: Florian Weimer To: Paul Eggert Cc: Bruno Haible , bug-gnulib@gnu.org, Karl Berry Subject: Re: scratch_buffer.h, scratch_buffer_dupfree.c sync References: <202211022237.2A2Mb6uK000339@freefriends.org> <3611769.t68216eyJU@nimes> <6854fb79-d7ec-615f-81f1-9a192ef52828@cs.ucla.edu> <1768975.kWiBISl1fq@nimes> <87v8nwfgg3.fsf@oldenburg.str.redhat.com> <2f9a6dd4-ebba-f452-6f30-635515f8c49f@cs.ucla.edu> Date: Thu, 03 Nov 2022 20:37:08 +0100 In-Reply-To: <2f9a6dd4-ebba-f452-6f30-635515f8c49f@cs.ucla.edu> (Paul Eggert's message of "Thu, 3 Nov 2022 11:26:45 -0700") Message-ID: <87o7tnesnv.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.5 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain Received-SPF: pass client-ip=170.10.133.124; envelope-from=fweimer@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -30 X-Spam_score: -3.1 X-Spam_bar: --- X-Spam_report: (-3.1 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.047, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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: > What problems do you see with the interfaces, and are there efforts to > come up with a better API? The need is there in GNU apps, each of > which tends to roll its own code here. dynarray has an aliasing violation in its implementation. The embedded pointer should be void * (not DYNARRAY_ELEMENT *), with casts added in the generated code, so that the out-of-line code can use the correct types. Defining the element free function has a trap for the unwary programmer: it's easy to miss the required pointer indirection. I don't know a good fix for that. I view dynarray as a stop-gap until we can use a C++ template inside glibc. We won't be able to use std::vector because of gaps in memory allocation failure handling, but application code interested in basic type-generic data structures should really use libstdc++ and not preprocessor hacks like dynarray. With such wide use of xmalloc & friends, the memory allocation issue would impact few applications. The scratch buffer interface is mainly intended as a helper for calling NSS functions because of their highly problematic buffer interface: it's not just that the caller allocates, the callee does not provide any size hint at all if the provided buffer is not large enough. So the only thing you can do is keep retrying with larger and larger buffers. No one should create interfaces like that. One could argue that scratch buffers are needed because the NSS interfaces exist today, but from a glibc perspective, I think we should provide replacements for the problematic NSS functions that are significantly easier to use, rather than relying on developers to put something together using scratch buffers. Maybe it's sufficient to make the original functions like getpwuid thread-safe, although such functions manipulating global state wouldn't be really library-safe. (You wouldn't want to call getpwuid in a library because it might clobber another getpwuid result still in use elsewhere, but that's an issue that is present with or without thread safety.) I added scratch_buffer_grow_preserve and scratch_buffer_set_array_size as an afterthought. Conceptually, they are unrelated to the NSS usage. They predate dynarrays. If dynarrays were easier to define, we should have switched over to them because they have implicit overflow checking for allocation sizes. Thanks, Florian