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.129.124]) by sourceware.org (Postfix) with ESMTPS id 5D3B3384DD1D for ; Mon, 20 Feb 2023 10:41:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5D3B3384DD1D Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1676889711; h=from:from:reply-to: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=sq720ADJoyJPl1VyvTME9yT7UY5b5KltHlCvSDQ1uZY=; b=I+EDQkeVV3BJZa40hauP0FHVon9T3J4IQW3IEEFJ4F/9VbSa21sxEgeY4b+TnHeGFnyf/8 oWtYj5ZsicwXIxaPIb2M8xU11bI3gYReymIk9wmbqS69VN93pasUZnXPVdw4mCrHECiDzZ WFdJa25RdRfxweMSDsNT3VRd7uJnejw= 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-135-RTgptetwNFmy8C1-soCHQw-1; Mon, 20 Feb 2023 05:41:50 -0500 X-MC-Unique: RTgptetwNFmy8C1-soCHQw-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.rdu2.redhat.com [10.11.54.2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 309408828CA; Mon, 20 Feb 2023 10:41:50 +0000 (UTC) Received: from calimero.vinschen.de (unknown [10.39.192.118]) by smtp.corp.redhat.com (Postfix) with ESMTPS id DEEFC40BC781; Mon, 20 Feb 2023 10:41:49 +0000 (UTC) Received: by calimero.vinschen.de (Postfix, from userid 500) id 88CC4A809BA; Mon, 20 Feb 2023 11:41:48 +0100 (CET) Date: Mon, 20 Feb 2023 11:41:48 +0100 From: Corinna Vinschen To: newlib@sourceware.org Cc: Giovanni Bajo Subject: Re: [PATCH] Allow fseek optimization also for cookied files. Message-ID: Reply-To: newlib@sourceware.org Mail-Followup-To: newlib@sourceware.org, Giovanni Bajo References: <20230219014020.92927-1-rasky@develer.com> MIME-Version: 1.0 In-Reply-To: <20230219014020.92927-1-rasky@develer.com> X-Scanned-By: MIMEDefang 3.1 on 10.11.54.2 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Spam-Status: No, score=-4.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Feb 19 02:40, Giovanni Bajo wrote: > Currently, fseek allows for a seek optimization where it does not > actually seek if the target is within the current buffer. This > optimization, though, is disabled in case of files with custom seek > functions, such as those created by funopen / fopencookie. > > This prevents a useful use case of those functions: creating a transparent > streaming decompressor (eg: gzopen). In fact, it is customary to > allow streaming decompressors to be able to seek forward (by skipping > bytes), but because of the missing seek optimization, even a simple > one-byte seek forward might become a backward seek (that is, a seek > that moves from the end of the current buffer backward to the seek > destination within the buffer). > > Since the check was explicit, there might be good reasons for it that > elude me. It looks to me that if buffering is allowed by files > returned by funopen, then the seek optimization cannot be a violation > of the funopen protocol, because otherwise it should also be invalid > to call the underlying readfn callback with size BUFSIZ when the user > requested a different size. People that want an absolute 1:1 match > between user-level calls and callbacks can obtain that by disabling > buffering. I'm not entirely sure about the reasing behind this, but the code in newlib in terms of the seek optimization is still equivalent to the upstream code in OpenBSD as well as FreeBSD. Changing such a crucial piece of code and deviating from upstream sounds like introducing subtil problems... Corinna