Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:112014 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 56180 invoked from network); 6 Oct 2020 14:21:14 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 6 Oct 2020 14:21:14 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 09D6A1804C6 for ; Tue, 6 Oct 2020 06:34:35 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Tue, 6 Oct 2020 06:34:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1601991272; bh=k+3tkCPQkzvCrE0akKnbljzcXE1e40k329GE3pycx9U=; h=X-UI-Sender-Class:From:Subject:To:Date; b=e086q/2idYS8VCOwudovSWQ4Ph4mCLHn303Ry9KdxZXchhuK89ILTz6yLnBPhVwwV lSyjmnjuWoNFXW72f6SacBrai+Zqq4kbbbI+MDOXx4oMZBxnDcFxGuxuiEtGEYzucC pAWj+lqzDEyyMO81udlYISGza4VFe/9NF0Drcru0= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.2.130] ([84.179.241.81]) by mail.gmx.com (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1Mt757-1kfXm52Hhh-00tUAz for ; Tue, 06 Oct 2020 15:34:32 +0200 X-Mozilla-News-Host: news://news.php.net:119 To: PHP Internals Message-ID: <7287c9a0-aeaf-1451-3f49-ac88aee187a0@gmx.de> Date: Tue, 6 Oct 2020 15:34:31 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.3.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: de-DE Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:pN1dP4cLKMp0+8bQDSPcVoh6hG5pj+bt8FN5sHWyI0eV8JluXlV HtqnEa76QvGEpnfk5ynV+mQRj+8kH29r85cKwLkdQNMi5QR9r8PHSG41PuxhIhQVfLFEQjL hLH4GsUBCY95oaksLGxzOZ9hSw0tjaOFqrVrVx/5Oj9gN+TnRjBag4+RINoLNHPvL/OM3hh rM+xhaLgPxlwVfeSbkyMw== X-UI-Out-Filterresults: notjunk:1;V03:K0:mu5Oh83nB3Y=:SvL6DOp1ZZBJm/3lTaZ+uM p3BQ6PWd0/STT7YMrYfsSXYj/Cuvim+HNwPJ4PNY++kcZK1DDXxrTHBR19ZHzGj3MFfmX2cWB mD/i0ma6amSSDtxajVe6qh9kcLOrgcbOwqt4iuI1HPy/qLpHbz+rk/euUSal9v69H0xrLMTI8 6SMgNmo1asB/8Mm5KL74l9QAqMEhN7Ry8rpiRWRGGHbsiZMcUNTIT+TYUVVsZGFDaTF57aBJu sQ45oiy1boJ9vXJ+9eZtFNpzPy1Dj+ccLotbDPzRuua7QjivN5Ha9osXdngPjdfLwVmxlTPpO uLrCfXFORHP74uDbkuBeQggaxEkOBa0HW50nYcFuiyK5kzHER7Ofj4v9X9ZzngkN7bhdEwp6D hC9uJsJYEa/3f5/jMO6Fm9igWl4EXOcLH7rr1/EPgPPFYq6v9OXAjq//ufv/4yj0U+SiCToQQ WKH5/mi9L5cL+lWftanVOwLVdsaaJtIFQunZN2/0g0e3o6ub77dR1kxVLIgAy5d97eFG2lFIM 4ap7TsGFjLLfiPCmDuzRjyt7aK1bmaIk+XOaQpdkYigykuSjhOhU4KfSX+R0eZN1QsN4y4j3Z liem7cGOgS48QDC6bEh43C/lgOyTxeM85iOxxHdIa6bo/DR7PPEn+XVpYFbJgYzn3NKv/4GXu OEsu4gLlsBCMHEFNfZOnuGcIvW1I7oJYeKwBwyk/Ua+ExO3yRcMvY/n9BrhwEBqWwSxaWfIx/ N6HfHwZdP2Cq9aj0nkMo7oSOl2Dh3j/tR3fQDgY4fuBmZtNSN4zHUPElTmKr8WHAyJLDemm3I EWlVZoDjyRz+T6YfHd7h8Vx1Is+r5BXn53IUP1r08rDLpa/Qj6wxtN5NtFVbjnga+8Bp66sVJ W+Acqctt++WOtV4W3ie2XDyk/yG9R6uNBi4mdwMrw+8JB8e1+WzHHm5GoLyG/Uor/t3GsoicA bN7BQUsG8sn7l1k1gvCQOios3Jmo2X56ZBXZKd2xsyy87gOjU1yoc/jOgLVPlTwoj3TsRMMi0 /weFcCM4YwKfNSrNZdSsxgu0Al9ri+7tA2dI6GQmGrt3ZRY0vmjqyVXs/o5ndwbP+0rlJF4s8 +3bhVUagHdhA/l6CpPzaXR4atX5gGQph0HvA4VhX5Gm70wAZjahxtnX42O50zUjO5n8PN7295 CBjQEheoLv3ylRKToaBNqRDxfS9e05Vg8MOPqK+ESa3AaXeNs+XVadimJvtXc+C6xDWJ3hyD7 dxigp0A5GVCJCGKIRiSrkAhRHifVVkxcOixC6OA== Subject: Stream filter may loose final block of data From: cmbecker69@gmx.de ("Christoph M. Becker") Hi all, as outlined in bug #77069[1], a stream filter may loose (aka. skip) the final data block. That bug report has some duplicates: #48725, #79984 and #77080. Several weaks ago I made PR #6001[2] which would fix this issue, but I'm not sure whether that change would violate the assumption that the PSFS_FLAG_FLUSH_CLOSE flag will only ever be passed if no further data is to be processed. Could someone more proficient with the streams layer than I am please clarify whether that is a valid assumption in the first place? [1] [2] Thanks, Christoph