Bug #80944 [Opn->Nab]: gzencode() sets a strange OS byte on Windows

Edit report at https://bugs.php.net/bug.php?id=80944&edit=1 ID: 80944 Updated by: cmb@php.net Reported by: christoph at burschka dot de Summary: gzencode() sets a strange OS byte on Windows -Status: Open +Status: Not a bug Type: Bug Package: Zlib related Operating System: Windows PHP Version: 8.0.3 -Assigned To: +Assigned To: cmb Block user comment: N Private report: N New Comment: I agree that this is a bug, but the maintainer of zlib thinks otherwise[1]. If you like feel free to bring that up with them. Anyhow, not a bug on the PHP side. [1] <https://github.com/madler/zlib/commit/ce12c5cd00628bf8f680c98123a369974d32df15#r31590394> Previous Comments: ------------------------------------------------------------------------ [2021-04-08 23:53:56] christoph at burschka dot de Description: ------------ The tenth byte of a gzip file identifies (in theory) the OS or file system on which the file was compressed. Running the test script on Linux produces a file where the byte is 0x03. On Windows, we get a somewhat strange value of 0x0A. (Meanwhile, the GnuWin utility on Windows set this byte to 0x0B for NT, while the gzip utility in Git Bash for Windows uses 0x03 as if it was Linux.) The standards document (RFC-1952) says that 0x0A is "TOPS-20", and sure enough - running the file utility on the resulting file shows: "test1.gz: gzip compressed data, from TOPS/20". I'm not sure if I can call this a bug, since it doesn't really matter in practice what gets written there (for example writing the same value on all platforms would be understandable), but it seems odd that we *do* get a platform-specific value, and it is for a different, long-dead platform. Test script: --------------- <?php file_put_contents('test1.gz', gzencode('Hello world')); ?> ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=80944&edit=1