From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from zimbra.cs.ucla.edu (zimbra.cs.ucla.edu [131.179.128.68]) by sourceware.org (Postfix) with ESMTPS id 3A971384385C for ; Fri, 24 Jun 2022 20:35:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 3A971384385C Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=cs.ucla.edu Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=cs.ucla.edu Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 7872B160102; Fri, 24 Jun 2022 13:35:38 -0700 (PDT) Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id A9Le2poFEjYY; Fri, 24 Jun 2022 13:35:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id BF574160107; Fri, 24 Jun 2022 13:35:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id huBKfrotZV4x; Fri, 24 Jun 2022 13:35:37 -0700 (PDT) Received: from [192.168.0.205] (ip72-206-2-24.fv.ks.cox.net [72.206.2.24]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 76149160102; Fri, 24 Jun 2022 13:35:37 -0700 (PDT) Message-ID: <71c2beba-ec0a-46e8-a212-c7ba8e866410@cs.ucla.edu> Date: Fri, 24 Jun 2022 15:35:36 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Subject: Re: [PATCH] stdio-common: Add the fgetln function Content-Language: en-US To: Florian Weimer Cc: libc-alpha@sourceware.org References: <871qxbxe2i.fsf@oldenburg.str.redhat.com> <577d0656-8b38-07d8-7b48-01870d3730c7@cs.ucla.edu> <87r13y5lth.fsf@oldenburg.str.redhat.com> <87fsjujpf4.fsf@oldenburg.str.redhat.com> From: Paul Eggert In-Reply-To: <87fsjujpf4.fsf@oldenburg.str.redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, NICE_REPLY_A, 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: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2022 20:35:40 -0000 On 6/24/22 06:01, Florian Weimer wrote: > We could avoid these > changes if we resized the buffer to twice the original buffer size. > Then we'd still maintain buffer read alignment, just with a larger > buffer. But that runs counter to the goal of avoiding extra > allocations. I'm not quite following. Since there would be just one buffer, that's one less memory allocation than the two buffers in the proposal. Yes, this single buffer might waste more total space due to the memory allocated between the buffer start and the line start. But I doubt whether it's worth the CPU time and complexity and data movement merely to avoid that space wastage. If the worry is that a 2x growth factor is overkill, we use a 1.5x growth factor (as in Gnulib's xpalloc function). It should be easy to maintain buffer read alignment regardless of growth factor.