From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: X-Spam-Status: No, score=-3.8 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.6 Received: from out1.vger.email (out1.vger.email [IPv6:2620:137:e000::1:20]) by dcvr.yhbt.net (Postfix) with ESMTP id 565841F47C for ; Thu, 12 Jan 2023 17:27:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230147AbjALR1g (ORCPT ); Thu, 12 Jan 2023 12:27:36 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52150 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231540AbjALR1M (ORCPT ); Thu, 12 Jan 2023 12:27:12 -0500 Received: from cloud.peff.net (cloud.peff.net [104.130.231.41]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C60AE8D5F6 for ; Thu, 12 Jan 2023 08:54:17 -0800 (PST) Received: (qmail 5725 invoked by uid 109); 12 Jan 2023 16:53:30 -0000 Received: from Unknown (HELO peff.net) (10.0.1.2) by cloud.peff.net (qpsmtpd/0.94) with ESMTP; Thu, 12 Jan 2023 16:53:30 +0000 Authentication-Results: cloud.peff.net; auth=none Received: (qmail 17005 invoked by uid 111); 12 Jan 2023 16:53:31 -0000 Received: from coredump.intra.peff.net (HELO sigill.intra.peff.net) (10.0.0.2) by peff.net (qpsmtpd/0.94) with (TLS_AES_256_GCM_SHA384 encrypted) ESMTPS; Thu, 12 Jan 2023 11:53:31 -0500 Authentication-Results: peff.net; auth=none Date: Thu, 12 Jan 2023 11:53:29 -0500 From: Jeff King To: =?utf-8?B?w4Z2YXIgQXJuZmrDtnLDsA==?= Bjarmason Cc: Derrick Stolee , git@vger.kernel.org, Jonathan Tan , =?utf-8?B?UmVuw6k=?= Scharfe Subject: Re: [PATCH 0/5] cleaning up read_object() family of functions Message-ID: References: <230112.86fscg2jbm.gmgdl@evledraar.gmail.com> <230112.86v8lbzpj1.gmgdl@evledraar.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <230112.86v8lbzpj1.gmgdl@evledraar.gmail.com> Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org On Thu, Jan 12, 2023 at 05:22:04PM +0100, Ævar Arnfjörð Bjarmason wrote: > We have members like "struct strbuf"'s "buf", which always needs to be > init'd, but never "maybe by the user", so the pattern above would work > there. We've discussed in the past having a strbuf that points to an existing buffer, over which it takes ownership. Or a const string that we'd leave behind (but not free) if we needed to grow. In those cases you'd want to pass in a buffer to the allocator. Of course in the case of a strbuf those initializers would probably just be totally separate from the regular slopbuf one, just because there's not much else in a strbuf to initialize. You don't gain much from trying to avoid repetition. > Anyway, I agree that it's not worth pursuing this in this case. > > But I think it's a neat pattern that we might find use for sooner than > later for something else. I remain unconvinced. ;) Mostly just that the lines saved versus the amount of magic and thought doesn't seem reasonable. But it's something we can keep in mind as new opportunities show up. -Peff