From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) by sourceware.org (Postfix) with ESMTPS id A41963858D38 for ; Sun, 19 Feb 2023 01:40:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A41963858D38 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=develer.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=develer.com Received: by mail-wr1-x42e.google.com with SMTP id s14so1395019wru.10 for ; Sat, 18 Feb 2023 17:40:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=develer.com; s=google; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=SGHQfLNLNbjF/ngQHwqvHkqR7IjrN3u/5UIz+xQVQWU=; b=QTHkez9J2S9b59b6iUFlqYvyv/IqAkiSiCiJVBxUF61u8B3ZZt9WcZvGoS2Ay0ZHmg Ug7Cb5UMWlM4785ZK+5EtT6pYDUL7CI1TRyeCuhqkzRFgyHhyVBz5WDIMCldnF+fDxUU JIWmLqJD4kT3hyNYsJpI/Ik1Yvj7Zs+ZGjkufGKBKgLT7Z6hiNOBDnsTAz0jl0/qTaNX GMmm94tT8YOc1t+tJuS104nQX32N1RVlt8Etj8MoYElj3uaFYlyV/GtG3RI8q2G9BLlG CWZObuEe+4720FViz2gwaMepsikXaZOgqgsIr9rukGPc1olB8R84zLLz9Qy7CDVuMwVA nQ+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=SGHQfLNLNbjF/ngQHwqvHkqR7IjrN3u/5UIz+xQVQWU=; b=iHKIaIepZJVN/nz7wUQZjaawRQu4MRH22FCpOwBS1q2NZY6Svahkf9kQ6Z/2H10tFi yW8W7pFfVYhXCrCGTIyrFqbbL65r4ZjK7I0MGxiJyE6VsE6gnAr+TQtv1mf8RYk9V863 Y0I5AfcWGxMOy02acpVrK8aIer+DNJuxVNcFUG88hqelyN3g3gQgeQXVZ4WO98i2LsKg qMQ4Dn1noM0UshLikFRcb8xzwzBBXVYG+FBOPlHMfVb9VrhJ99vIzOCUOOmG4Zk8X6DA PjR9Gkm9My1rNdiwxAFL89wI20D2Y5nRSNb1MeR4lxGHPQuixccKaL3EUfciFe6TRM87 U7Tg== X-Gm-Message-State: AO0yUKVCVePHsCykfqUe30IB+PJ0eHCFnoxYK9Qy2OTGY33Sf0WvYWNX +k3HXGpmlD+ql3ovbitHehvWeGkTC5CcB1XEuNk= X-Google-Smtp-Source: AK7set9JGN5GMpFgAsU4I6N7189G4UAUHOwBiGawp7HULiN1Pve8olHB7x1K6u9dVjf/o+nmHSqAhA== X-Received: by 2002:a5d:4b06:0:b0:2c5:93a0:3bd2 with SMTP id v6-20020a5d4b06000000b002c593a03bd2mr1680202wrq.14.1676770824496; Sat, 18 Feb 2023 17:40:24 -0800 (PST) Received: from localhost.localdomain ([145.224.103.247]) by smtp.gmail.com with ESMTPSA id i17-20020adfefd1000000b002c55551e6e9sm747025wrp.108.2023.02.18.17.40.23 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Sat, 18 Feb 2023 17:40:23 -0800 (PST) From: Giovanni Bajo To: newlib@sourceware.org Cc: Giovanni Bajo Subject: [PATCH] Allow fseek optimization also for cookied files. Date: Sun, 19 Feb 2023 02:40:20 +0100 Message-Id: <20230219014020.92927-1-rasky@develer.com> X-Mailer: git-send-email 2.39.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-13.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,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: 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. --- newlib/libc/stdio/fseeko.c | 8 +++----- newlib/libc/stdio64/fseeko64.c | 8 +++----- 2 files changed, 6 insertions(+), 10 deletions(-) diff --git a/newlib/libc/stdio/fseeko.c b/newlib/libc/stdio/fseeko.c index 6fcc8ef06..2dfb4e3db 100644 --- a/newlib/libc/stdio/fseeko.c +++ b/newlib/libc/stdio/fseeko.c @@ -185,9 +185,8 @@ _fseeko_r (struct _reent *ptr, /* * Can only optimise if: - * reading (and not reading-and-writing); - * not unbuffered; and - * this is a `regular' Unix file (and hence seekfn==__sseek). + * reading (and not reading-and-writing); and + * not unbuffered. * We must check __NBF first, because it is possible to have __NBF * and __SOPT both set. */ @@ -200,8 +199,7 @@ _fseeko_r (struct _reent *ptr, goto dumb; if ((fp->_flags & __SOPT) == 0) { - if (seekfn != __sseek - || fp->_file < 0 + if (fp->_file < 0 #ifdef __USE_INTERNAL_STAT64 || _fstat64_r (ptr, fp->_file, &st) #else diff --git a/newlib/libc/stdio64/fseeko64.c b/newlib/libc/stdio64/fseeko64.c index c5b30aed0..bdee9601f 100644 --- a/newlib/libc/stdio64/fseeko64.c +++ b/newlib/libc/stdio64/fseeko64.c @@ -186,9 +186,8 @@ _fseeko64_r (struct _reent *ptr, /* * Can only optimise if: - * reading (and not reading-and-writing); - * not unbuffered; and - * this is a `regular' Unix file (and hence seekfn==__sseek). + * reading (and not reading-and-writing); and + * not unbuffered. * We must check __NBF first, because it is possible to have __NBF * and __SOPT both set. */ @@ -201,8 +200,7 @@ _fseeko64_r (struct _reent *ptr, goto dumb; if ((fp->_flags & __SOPT) == 0) { - if (seekfn != __sseek64 - || fp->_file < 0 + if (fp->_file < 0 || _fstat64_r (ptr, fp->_file, &st) || (st.st_mode & S_IFMT) != S_IFREG) { -- 2.39.0