From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9447 invoked by alias); 13 Nov 2019 10:15:35 -0000 Mailing-List: contact newlib-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: newlib-owner@sourceware.org Received: (qmail 9438 invoked by uid 89); 13 Nov 2019 10:15:35 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-3.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.1 spammy=1994, HX-Languages-Length:934, positions, our X-HELO: us-smtp-1.mimecast.com Received: from us-smtp-delivery-1.mimecast.com (HELO us-smtp-1.mimecast.com) (205.139.110.120) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 13 Nov 2019 10:15:34 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1573640133; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references; bh=OymZGeQYeShMRYtIvV4PAnAk4+sdZhF+lQG3J/H49xw=; b=gaByVhGUa5h2r3ehd9yt2BXL7fUc/KGfqhRj6UjBC44ClxqFNnwmf1pSb62796W2u5FwyP Nq49V3lFZCm+sowtlUcZjVUplpBZSVl1BVZNb/16r8Z6x8qzVfo6Mvg5dETnNd2GwvZXeH PjXa/ZjBRWug50m1e+E+tD3Z45ZdyNM= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-188-SCywDyu1PVChRRzTtVGGmA-1; Wed, 13 Nov 2019 05:15:31 -0500 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id B5E66801FD2 for ; Wed, 13 Nov 2019 10:15:30 +0000 (UTC) Received: from calimero.vinschen.de (ovpn-116-45.ams2.redhat.com [10.36.116.45]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 7E7EC60850 for ; Wed, 13 Nov 2019 10:15:30 +0000 (UTC) Received: by calimero.vinschen.de (Postfix, from userid 500) id 0BCAEA809F3; Wed, 13 Nov 2019 11:15:29 +0100 (CET) Date: Wed, 13 Nov 2019 10:15:00 -0000 From: Corinna Vinschen To: newlib@sourceware.org Subject: Re: [PATCH] newlib: fix fseek optimization with SEEK_CUR Message-ID: <20191113101528.GQ3372@calimero.vinschen.de> Reply-To: newlib@sourceware.org Mail-Followup-To: newlib@sourceware.org References: <20191109162804.1905160-1-bastien.bouclet@gmail.com> MIME-Version: 1.0 In-Reply-To: <20191109162804.1905160-1-bastien.bouclet@gmail.com> User-Agent: Mutt/1.12.1 (2019-06-15) X-Mimecast-Spam-Score: 0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="MEatx1zidE5asLAI" Content-Disposition: inline X-SW-Source: 2019/txt/msg00637.txt.bz2 --MEatx1zidE5asLAI Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 884 Hi Bastien, On Nov 9 17:28, Bastien Bouclet wrote: > The call to fflush was invalidating the read buffer, preventing relative > seeks to positions that would have been inside the read buffer from > being optimized. The call to srefill would then re-read mostly the same > data that was initially in the read buffer. I checked this against upstream BSD versions. OpenBSD and NetBSD operate like our code, including the flush, while FreeBSD uses its internal ftello and never flushed since the repository import back in 1994. I'm pretty unsure if we can do this. Apparently the flush op is only necessary for streams in append mode. If at all. Can we be sure this works as desired on append streams as well? Also, given that this is changing very basic code, nobody is unaffected. Any input from other folks? Thanks, Corinna --=20 Corinna Vinschen Cygwin Maintainer Red Hat --MEatx1zidE5asLAI Content-Type: application/pgp-signature; name="signature.asc" Content-length: 833 -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEoVYPmneWZnwT6kwF9TYGna5ET6AFAl3L18AACgkQ9TYGna5E T6BYOA/+KdxLoh89ztaUVmg2IqM3AT4ipQ1eW1EMJD4Y26lTb8A2mltQz4tXpKQZ jllJ0SO8IXCzpXmQomCycU45Hz+ARmiYX7s+LZujD+fWn06RB5CgZzhpXqqNNDAG 9TpH1H3jxtJpLgc2b+gCr7Lcip9MwywPlQGkuNdHF6ml7/vX/fLIMAg4KZXSNWmN JPzVNb5MThjZZQ+rsgagxPo64I2TTR2jwxvhZ90YLuGz3ofhRl82fUwU9SR1668j 5To/TjsQFD/bwf3DhaSuvguKXUUKsdkPBr6dIKAUqmIwCT+LCcsHGmzjB6LJtzeb l9qW4Ws01rDd1PGuWJlsqrVcErqa7qR2xBN8SI+v60A1FcOmsMM0m1yUJAnUTaUm eTm9sArm99/abnNQyxm9I7Jd6a2qhKYU8D6WJVYzfgwTIkW38xlWyQlhmLhtacn7 HjB7cWtiDQkFufmQO71k/OmPwEzGG67hqjRqP+bKjDuBP7WW1VJf4Kyr1lbNXqoK 3xfBiJ+AQFtxUCiUNLNfLRuzKnrqZfl7CXuQ8uBOaIu3+tFaVtJY3/1UB/UPOte6 flzm4p4iCtnYjaOFVX1iuQkKKOUpgOdXfKKuAY9fY3xp+HsvrIp6GiBKlBQqsteo UBTlo9e7QQBXcTEvWsD1aFFkqdZ1KXFMH9eljhAF3iOdiHFZmwA= =r9jb -----END PGP SIGNATURE----- --MEatx1zidE5asLAI--