From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 82E69385803E for ; Tue, 3 May 2022 08:31:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 82E69385803E Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-158-UveuV6QKN-CmglMS_ngiOg-1; Tue, 03 May 2022 04:31:08 -0400 X-MC-Unique: UveuV6QKN-CmglMS_ngiOg-1 Received: from smtp.corp.redhat.com (int-mx09.intmail.prod.int.rdu2.redhat.com [10.11.54.9]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 059BF811E80; Tue, 3 May 2022 08:31:08 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.39.192.44]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 358DA568CAC; Tue, 3 May 2022 08:31:07 +0000 (UTC) From: Florian Weimer To: Andreas Schwab Cc: Florian Weimer via Libc-alpha Subject: Re: [PATCH] stdio-common: Add the fgetln function References: <871qxbxe2i.fsf@oldenburg.str.redhat.com> <87ee1bf3b6.fsf@igel.home> Date: Tue, 03 May 2022 10:31:05 +0200 In-Reply-To: <87ee1bf3b6.fsf@igel.home> (Andreas Schwab's message of "Tue, 03 May 2022 10:06:21 +0200") Message-ID: <87r15bvwza.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 2.85 on 10.11.54.9 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-5.1 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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: Tue, 03 May 2022 08:31:10 -0000 * Andreas Schwab: > On Mai 03 2022, Florian Weimer via Libc-alpha wrote: > >> +/* Reads the next line from STREAM and returns a pointer to the start o= f > Read return > >> + an array containing it. The array is not null-terminated. The > > That makes it a rather clunky interface. Why do we need that, given > getline et al? Unfortunately, some software uses this function. It cannot be reliably implemented outside of libc, and there are some really problematic portability wrappers out there. For example, the libbsd implementation is not thread-safe, and has a use-after-free condition if more than 32 streams are used: | static struct filebuf fb_pool[FILEBUF_POOL_ITEMS]; | static int fb_pool_cur; [=E2=80=A6] | |=09/* Try to diminish the possibility of several fgetln() calls being |=09 * used on different streams, by using a pool of buffers per file. */ |=09fb =3D &fb_pool[fb_pool_cur]; |=09if (fb->fp !=3D stream && fb->fp !=3D NULL) { |=09=09fb_pool_cur++; |=09=09fb_pool_cur %=3D FILEBUF_POOL_ITEMS; |=09=09fb =3D &fb_pool[fb_pool_cur]; |=09} |=09fb->fp =3D stream; Thanks, Florian