bug#79087: gzip 1.9.7 - z17 Compatibility

On 2025-07-24 01:13, MATHEW THOMAS via GNU gzip discussion and bug reports. wrote: We are currently running gzip 1.9.7 on z/OS 3.1. We plan to migrate to the z17 hardware and would like to know if there are any required actions to take for this product, such as upgrading or applying any fixes

bug#78799: Zip created by pigz is deemed to be corrupted

it's not needed. I will provide a patch to gzip to process the Zip64 extra field, to replace the current “unsupported” error message. Thanks for volunteering!From 386f4fa1112b6554772e8c2cca0d77d984f58e1c Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Tue, 17 Jun 2025 08:51:33 -0700 Su

bug#78799: Zip created by pigz is deemed to be corrupted

crc */ -if (pkzip && !ext_header) { /* crc and length at the end otherwise */ - orig_crc = LG(inbuf + LOCCRC); -orig_len = LG(inbuf + LOCLEN); -} - /* Decompress */ if (method == DEFLATED) { @@ -150,13 +183,7 @@ unzip (int in, int out) } else if (pkzip

bug#78799: Zip created by pigz is deemed to be corrupted

On 2025-06-15 09:46, Adler, Mark wrote: It was not clear, but this is a gzip report, not a pigz report. Ah, thanks for letting me know. I reopened the gzip bug report. Maybe someday somebody can get around to looking into the issue on the gzip side.

bug#78799: Zip created by pigz is deemed to be corrupted

On 2025-06-15 08:25, Adler, Mark wrote: The problem is with the “other un/zippers” which per the linked report on sourceforge is actually just 7-Zip. Thanks for diagnosing; closing the gzip bug report.

bug#78618: Gzip 1.14 build failure on s390x (undeclared errno in dfltcc.c)

Thanks for reporting that. I installed the attached slightly-different patch (different because it includes errno.h in same order as other files).From c76affb4551630ff661ac1c1ee99353a17eb16e1 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Fri, 30 May 2025 12:31:04 -0700 Subject: [PATCH] gzip

bug#78639: Uninitialised read in check_zipfile() (gzip 1.14)

Thanks, I installed the attached additional patch.From b1de0e782a291c46e26777005893eeca142e0490 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Fri, 30 May 2025 12:23:42 -0700 Subject: [PATCH] gzip: fix another uninitialized read MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content

bug#78639: Uninitialised read in check_zipfile() (gzip 1.14)

00:00 2001 From: Paul Eggert Date: Thu, 29 May 2025 23:06:19 -0700 Subject: [PATCH] gzip: fix uninitialized read MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Problem reported by Mohamed Maatallah <https://bugs.gnu.org/78639>. * unzip.c (check_zipf

bug#77807: Compilation of gzip 1.13 fails on PPC Tiger, Mac OS X 10.4.11

On 2025-04-15 03:14, Peter Dyballa wrote: Yes, compiles fine, except for some warnings: The warnings are false alarms; you can ignore them. Glad to hear that gzip compiles now. Closing the bug report. + perl -e ' use POSIX qw(dup2); $SIG{PIPE} = "DEFAULT"; pipe my ($read

bug#77807: Compilation of gzip 1.13 fails on PPC Tiger, Mac OS X 10.4.11

On 2025-04-16 02:54, Peter Dyballa wrote: Testing misses two files to exclude – new bug report? I suppose so, yes - for Tar.

bug#78084: "od: invalid option -- 'A'" issue when run gzip-1.14 tests

Thanks for reporting that glitch with busybox. I installed the attached to work around it.From e77940b44f8804ca7b59606af2f9318d5bc954e2 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sun, 27 Apr 2025 13:28:20 -0700 Subject: [PATCH] tests: port to Busybox od Problem reported by Xinjian Ma (Bug

bug#77807: Compilation of gzip 1.13 fails on PPC Tiger, Mac OS X 10.4.11

Please try gzip 1.14 instead, as it has fixes in at least some of the areas that gave you trouble.

bug#77640: [platform-testers] new snapshot available: gzip-1.13.56-e549

On 2025-04-10 15:13, Nelson H. F. Beebe wrote: I made this change against the original test file: % diff dfly-openat-bug.c dfly-openat-bug-3.c 8c8 < int dirfd = open ("d/", O_SEARCH | O_DIRECTORY); --- > int dirfd = open ("d/", O_RDONLY | O_DIRECTORY)

bug#77724: [PATCH] maint: include errno.h

On 2025-04-10 22:27, Andreas Stieger via GNU gzip discussion and bug reports. wrote: Found building for s390x on openSUSE --- dfltcc.c | 1 + 1 file changed, 1 insertion(+) diff --git a/dfltcc.c b/dfltcc.c index 9f86581..7333757 100644 --- a/dfltcc.c +++ b/dfltcc.c @@ -18,6 +18,7 @@ #include #in

bug#77640: [platform-testers] new snapshot available: gzip-1.13.56-e549

On 4/10/25 09:59, Nelson H. F. Beebe wrote: I tried that, and gcc reported that O_SEARCH is unknown, and suggested ``did you mean 'O_EXCL'?''. Oh, I thought DragonflyBSD was like other BSDs. My mistake; says it has neither O_S

bug#77640: [platform-testers] new snapshot available: gzip-1.13.56-e549

On 2025-04-09 05:47, Nelson H. F. Beebe wrote: I ran these tests in the gzip-1.13.56-e549 build directory on DragonFlyBSD 6.4.0: mkdir d echo >d/f chmod a-w d env LC_ALL=C truss -o gzip.truss ./gzip d/f That last command produces this output; gzip: d/f.g

bug#77640: [platform-testers] new snapshot available: gzip-1.13.56-e549

On 2025-04-08 11:43, Nelson H. F. Beebe wrote: Here is the requested test on DragonFlyBSD for gzip-1.13.56-e549: % cat foo.sh #! /bin/sh mkdir d echo >d/f chmod a-w d ./gzip d/f % ./foo.sh gzip: d/f.gz already exists; do you wish to overwrite (y or n)? y gzip: d/f.gz: No such file or directory

bug#77640: [platform-testers] new snapshot available: gzip-1.13.56-e549

On 4/8/25 14:16, Nelson H. F. Beebe wrote: Thanks for this analysis of the gzip-1.13.56-e549 test failures on DragonFlyBSD 6.4.0: If you can concoct a small C program that is likely to be runnable across a range of systems, then I'll be happy to configurize it, and then do tests builds on our tes

bug#77641: [platform-testers] new snapshot available: gzip-1.13.56-e549

On 2025-04-08 11:25, Nelson H. F. Beebe wrote: Here is the output on NetBSD 10.0 for the test script for zdiff behavior: Thanks. I'm quoting it below. Apparently the equivalent of the following crashed: echo b >b gzip b gzip_status=$(gzip -cdfq -- b.gz) whereas the same thing succeeded if o

bug#75924: maint: fix s390 buffer flushes

On 2025-02-20 03:33, Eduard Stefes wrote: I think we are at a solid state here, as both implementations run with the same test suit. Investing more time to get a 100% error message overlap looks like a bigger effort. We know that the hardware state machine does not simply map the software, so I f

bug#77640: [platform-testers] new snapshot available: gzip-1.13.56-e549

On 2025-04-08 06:07, Nelson H. F. Beebe wrote: + mkdir d + echo + chmod a-w d + test -w d + id -u + test 887 '=' 0 + returns_ 1 gzip d/f + fail=1 To help debug this problem on DragonFlyBSD 6.4.0, please run the following commands in the gzip source directory and tell us what the ./gzip does:

bug#77641: [platform-testers] new snapshot available: gzip-1.13.56-e549

On 2025-04-08 06:12, Nelson H. F. Beebe wrote: + returns_ 1 zdiff a.gz b.gz >out 2>err + fail=1 To help debug that, could you please run the following commands in the gzip source directory and tell us the output? echo a>a echo b>b ./gzip a b /bin/bash -x ./zdiff a.gz b.gz I am assuming "zdi

bug#76644: 1.13 fails to build on s390x: alignas gone

Thanks for the bug report. This appears to be the same as the following issue reported by Sarah-Julia Kriesch, and you can see a fix there: https://bugs.gnu.org/66709 For now, I'll merge the two bug reports.

bug#76197: [PROPOSED] gzip: drop support for the GZIP env var

Savannah master gzip. It means gzip will pay attention to -1..-9, --rsyncable, and --synchronous but will silently ignore everything else in GZIP. The idea is that a garbage GZIP value shouldn't disrupt normal operations. From 02cde43286da3b47182daac61352fa26ed35e2ea Mon Sep 17 00:00:00 20

bug#75924: maint: fix s390 buffer flushes

On 2025-02-17 02:38, Eduard Stefes wrote: I came up with an ugly hack: Thanks, it sounds much nicer than the hack I was thinking of, which was to redo the entire run in software

bug#72588: Fwd: Re: performance bug regarding CRC32 algorithm implementation

[Resending because my earlier email had the wrong bug number.] Due to work by Sam Russell and others it looks like gzip now has faster CRC32 code on Savannah master, so closing this old bug report. See: https://bugs.gnu.org/74927 https://bugs.gnu.org/74192--- Begin Message --- Due to work by S

bug#67022: Gzip decompression can be 60% faster using zlib's CRC32

On 2023-11-09 10:32, Paul Eggert wrote: On 2023-11-09 09:40, Young Mo Kang wrote: Since both GNU Gzip and zlib are written by the same authors, I was wondering if GNU Gzip can share zlib's CRC32 calculation and obtain this performance gain--I am not sure if there would be a license

bug#72989: Avoid using postal address in license.

On 2024-09-02 12:13, Collin Funk wrote: Following Simon's patch in Gnulib, replacing the old FSF postal address with a link [1]. Thanks, I see Jim installed something similar into gzip soon after you sent this email, so I'm closing the bug report.

bug#72772: DEPRECATED

On 2024-08-23 you wrote: root@INF-DESKTOP:/tmp# GZIP=-1 tar cfz saved.config.tar.gz saved.config gzip: warning: GZIP environment variable is deprecated; use an alias or script Yes, that's the intended and documented behavior. The GZIP environment variable can make it hard to write portable sc

bug#76197: [PROPOSED] gzip: drop support for the GZIP env var

The GZIP environment variable is too hazardous. * gzip.c (env, ENV_OPTION): * tailor.h (OPTIONS_VAR): * util.c (SEPARATOR, add_envopt): Remove. All uses removed. * gzip.c (main): Ignore GZIP. * tests/gzip-env: Test that GZIP is ignored. --- NEWS | 6 doc/gzip.texi | 11 ++- g

bug#74927: [PATCH] build: update gnulib, include crc-x86_64 module

Thanks, I installed the attached somewhat-fancier patches which should do the same thing; please see what you think. Boldly closing bug#74927.From 6b65e654a74998705da3aed81d1bbb57f50847eb Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Mon, 10 Feb 2025 22:31:36 -0800 Subject: [PATCH 1/2] gzip

bug#74192: [PATCH] build: update gnulib to latest, to enable faster crc

Marking this bug report as done because Jim updated gzip to the latest Gnulib on December 13, after this patch was submitted.

bug#75924: maint: fix s390 buffer flushes

On 2025-02-05 07:46, Eduard Stefes wrote: We think that the only possibility for a problem here, is if faulty hardware updates param->cf incorrect. I'd rather not worry about hardware going bad, unless the hardware failure is a known real-world problem. So how about if we make the following

bug#75924: maint: fix s390 buffer flushes

en be zero, so that gzip will go into an infinite loop attempting to read past EOF?From 51088970d45baedba4739632305d1dbc5acbb3bf Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Wed, 29 Jan 2025 10:52:49 -0800 Subject: [PATCH] gzip: fix problem with s390 buffer flushes Problem reported

bug#75405: gzip --synchronous doesn't work with musl

Thanks, I installed that test. Marking this gzip bug as done.

bug#75405: gzip --synchronous doesn't work with musl

On 2025-01-07 10:22, Lasse Collin wrote: However, one thing that isn't an issue in musl is fchmod which is currently documented in Gnulib's doc/posix-headers/fcntl.texi. fchmod and a few others were fixed in 2013 by using /proc/self/fd.[1] Is that a full fix, though? /proc might not be mounted

bug#75405: gzip --synchronous doesn't work with musl

On 2025-01-06 05:29, Lasse Collin wrote: In musl, O_SEARCH maps to Linux-specific O_PATH That is a bug in musl. musl should not define O_SEARCH to O_PATH on Linux, because O_PATH is not a valid implementation of O_SEARCH. Or if musl wants to do some sort of approximate-but-invalid implementa

bug#74196: maint: assume proper behavior of tolower

On 2024-11-11 10:42, Collin Funk wrote: I doubt MSDOS, OS2, ATARI would be supported by Gnulib. Not only are they not supported by Gnulib, I'm sure gzip hasn't worked on them for decades. We just haven't bothered to rip out all the supporting code.

bug#74192: [PATCH] build: update gnulib to latest, to enable faster crc

On 2024-11-03 01:52, Sam Russell wrote: * lib/striconv.c (str_iconv): Remove glibc-2.1 bug workaround. * lib/striconveh.c (iconveh_open): Likewise. Not sure if that means glibc 2.1 is deprected, I think it does, but we don't need to worry about that. Thanks for the heads-up. I have

bug#73814: [PATCH] maint: Drop unused sample/makecrc.c.

Thanks, I installed that.

bug#73402: Switch scripts from using `type` to `command -v` to support non-XSI POSIX shells, or specify bash?

Thanks for the bug report. I installed the attached patch to fix the bug and am boldly closing the bug report. If the patch doesn't work for you, please let us know and we can reopen the bug report.From 602fa20438cddaa8ede84828b6fbe42a06d49392 Mon Sep 17 00:00:00 2001 From: Paul Eggert

bug#72472: gzip: simplify printing of offsets using -l and -v

On 2024-08-13 09:20, Jim Meyering wrote: While somewhat related, I don't see how an async-safe strcpy would let us remove that function. Agreed. You can't even use strcpy on 'char volatile *'; C prohibits that. Async safety is about something else (admittedly brain-hurting :-).

bug#72587: Getting compilation error

On 2024-08-11 17:55, Daniel Ruf via GNU gzip discussion and bug reports. wrote: dup2.c:80:11: error: cast from function call of type 'intptr_t' {aka 'long long int'} to non-matching type 'void *' [-Werror=bad-function-cast] 80 | if ((HANDLE) _get_osfhandle (fd) == INVALID_HANDLE_VALUE) | ^ cc1: a

bug#72283: Path traversal in gzip's -S option

2001 From: Paul Eggert Date: Wed, 24 Jul 2024 19:13:51 -0700 Subject: [PATCH] gzip: reject suffixes containing '/' Problem reported by Alex Stumpf <https://bugs.gnu.org/72283>. * gzip.c (main): Diagnose suffixes containing '/', and exit. --- NEWS | 2 ++

bug#72050: TileBuilder gunzip Command using older version

On 7/10/24 22:02, Gohar, Shaheer via GNU gzip discussion and bug reports. wrote: I was running a perl script in TileBuilder after testing it in Linux and noticed that 'gunzip -k' is not available. It looks like they are running two different versions of gzip (white terminal is running at vers

bug#70862: 'write-error' test fails on NetBSD when run as root

Thanks, I installed that fix.

bug#70430: VMS/VAX GZIP 1.3.12e deletes wrong file, doesn't honor file version number

On 2024-04-16 11:10, Mark Diaz wrote: Sorry if this is a known issue or has already been corrected Your bug report is about gzip 1.3.12 (2007-04-13). Unfortunately gzip's support for VMS was removed in gzip 1.9 (2018-01-07) and (as you're noticing) it wasn't really working even before that. U

bug#69771: (no title)

On 2024-03-12 23:10, lgtogg via GNU gzip discussion and bug reports. wrote: Hello, I have an error when I am building gzips. How can I fix it? The error message is as follows: qwe@qwe-pc:~/桌面/gzip-1.9$ makemake  all-recursive gzip 1.9 is six years old and I wouldn't be surprised if it didn't

bug#69789: zcat, zgrep and other (g)zutils' names

On 2024-03-13 15:54, wrotycz wrote: I propose to rename zcat, zgrep, etc., to gzcat, gzgrep, etc That's already doable when building gzip; you can use './configure --program-prefix'. Run './configure --help' for more, or see the file INSTALL.

bug#68329: '--list' fails on multimember files

Thanks for reporting and diagnosing that gzip bug. I installed the attached patch to fix it, and to add a regression test.From 607bc945230c9fdcad24527578bf3605f446dc7c Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Mon, 8 Jan 2024 20:39:05 -0800 Subject: [PATCH] gzip: fix -l bug with

bug#67022: Gzip decompression can be 60% faster using zlib's CRC32

On 2023-11-09 09:40, Young Mo Kang wrote: Since both GNU Gzip and zlib are written by the same authors, I was wondering if GNU Gzip can share zlib's CRC32 calculation and obtain this performance gain--I am not sure if there would be a license issue though. Shouldn't be a license issue. It's ju

bug#66709: gzip build fails on s390x because (version 1.13)

ar in the next gzip release. In the meantime you should be able to build on s390x by compiling with 'gcc -Dalignas=_Alignas'.From 900ecfd89fbe426c4cd1e2a86b0381d3d4050749 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Mon, 23 Oct 2023 13:12:10 -0700 Subject: [PATCH] maint: fix port to s3

bug#64118: [PATCH] gzip.1: some remarks and formatting fixes for the man page

ros, just as I suppose I spend too much time today hacking on Perl scriptsFrom 3a29557bf901f94cc213e1e5b8b1eb5f03d6cac7 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sun, 18 Jun 2023 00:27:52 -0700 Subject: [PATCH] Update \(en in copyright notices * build-aux/update-copyright (ndash_re): N

bug#64118: [PATCH] gzip.1: some remarks and formatting fixes for the man page

Thanks, I installed the attached, which isn't the same as what you sent but I hope it addresses the same editorial issues.From 97c3d5b3da78b39a715451e52265cd0579dd23ab Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Fri, 16 Jun 2023 15:21:24 -0700 Subject: [PATCH] doc: minor tuneup of man

bug#62778: continuous integration test failure

Thanks, I installed that.

bug#62197: Bug "No space left on device"

On 2023-03-14 17:31, Isaque Lucas wrote: I tried to decompile the disk file of the 'UnforgottenBits' challenge in /tmp directory, as requested in the notes, but the result is "No space left on device". The commands I've researched to solve this issue don't work on picoCTF terminal. Thanks for the

bug#61187: continuous integration

On 1/30/23 13:46, Bruno Haible wrote: 1) bootstrap.conf specifies that 'rsync' is needed. But rsync is not needed any more by 'gnulib-tool' and by 'bootstrap' since 2018-10-07. Thanks, I in

bug#61186: build failure when building from git source in a subdirectory

Thanks, I installed that.

bug#60924: gunzip susceptible to PATH highjacking

On 2023-01-17 20:39, Peter Hutterer wrote: Not sure if this is a bug, intentional, or just a "meh, too niche to worry about". I'd say it's intentional. These days you're probably better off linking to zlib instead.

bug#60326: [PATCH 1/2] maint: link with $(LIB_FDATASYNC)

* Makefile.am (gzip_LDADD): Add LIB_FDATASYNC as gnulib-tool suggests. It’s not likely to make much difference nowadays (does anybody still run Solaris 10 x86?) but it shouldn’t hurt to add it. --- Makefile.am | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Makefile.am b/Mak

bug#60326: [PATCH 2/2] gzip: use strerror, not perror

* bootstrap.conf (gnulib_modules): Use strerror, not perror. This removes dependencies on Gnulib’s ‘threadlib’ and ‘lock’ modules, and simplifies the mainline code. Apparently the old code was written before strerror was universally supported; nowadays we can use Gnulib strerror instead. All uses

bug#56749: modernize bootstrap.conf

On 12/25/22 20:36, Paul Eggert wrote: I installed the attached patch to gzip and updated the bootstrap script to current Gnulib. Unfortunately that didn't work because the new bootstrap script comes in two flavors: a standalone gnulib/build-aux/bootstrap that automatically replaces i

bug#60326: [PATCH] maint: do not include stdbool.h, stdalign.h

They are not needed in C23, which Gnulib now emulates. (We no longer worry about C89, since Gnulib doesn’t.) --- dfltcc.c | 2 -- gzip.c| 2 -- inflate.c | 1 - 3 files changed, 5 deletions(-) diff --git a/dfltcc.c b/dfltcc.c index b9eaf5e..50632d0 100644 --- a/dfltcc.c +++ b/dfltcc.c @@ -18

bug#23958: Intermittent failure to compress

On 7/12/16 13:22, Paul Eggert wrote: On 07/12/2016 08:01 PM, Office Info wrote: the MacPractice IT guys say that it is a failure with the gzip That's pretty vague, unfortunately. What exactly is the bug? Can you give us a recipe so that we can reproduce the bug? No further comment i

bug#26088: BusyBox support

On 3/14/17 15:25, Paul Eggert wrote: On 03/14/2017 05:03 AM, Denys Zagorui wrote: Hello, thank you for reply. I'd not attach patch for zless. This patch only for tests/zdiff test, with this patch this test (tests/zdiff) work with diff from busybox and diff from diffutils Sorry, I

bug#29261: Save/restore dates does not work properly

On 11/11/17 15:19, Paul Eggert wrote: Can you reproduce the problem with the current version? No further comment in five years, so closing this old bug report.

bug#32415: Possible ug in gzip 1.8

On 8/10/18 14:02, Paul Eggert wrote: What platform and gzip version are you using, and how was gzip built and installed? Can you reproduce the problem? Better yet, can you show us how to reproduce the problem? No further comment in four years, so I'm closing this old bug report.

bug#49850: Crosscompiling gzip for musl-based system with clang

No further comment on this old bug report, so I'm taking the liberty of closing it.

bug#54759: Compile error on macOS w/ gcc

On 4/7/22 15:57, Paul Eggert wrote: Thanks for the bug report. Please try gzip 1.12, released today. It has bug fixes (inherited from Gnulib) in the area you reported, and should build on macOS with GCC. Thanks. No further comment, so I assume this old bug report no longer applies to current

bug#29265: gzip-1.8.41 test results: timestamp

On 11/12/17 00:25, Paul Eggert wrote: I installed the attached patch to tests/timestamp As this appears to have fixed the bug, I'm closing this old bug report.

bug#56749: modernize bootstrap.conf

Thanks for the heads-up. I installed the attached patch to gzip and updated the bootstrap script to current Gnulib.diff --git a/README-hacking b/README-hacking index 60e40ca..4af67f4 100644 --- a/README-hacking +++ b/README-hacking @@ -63,6 +63,17 @@ and the Git master copy: should output no di

bug#60327: [COMMITTED] maint: port to gcc -std=c99 -Wstrict-prototypes

This doesn’t fix any bugs, since the code is correct as-is on all C versions. However, it pacifies gcc -std=c99 -Wstrict-prototypes, which complains about a function definition without arguments unless there’s a previous prototype with ‘(void)’. Most (but not all) of this patch merely reverts some

bug#60326: [COMMITTED 3/8] maint: stop using obsolete fdl module

--- bootstrap.conf | 1 - doc/.gitignore | 1 - doc/fdl.texi | 505 + 3 files changed, 505 insertions(+), 2 deletions(-) create mode 100644 doc/fdl.texi diff --git a/bootstrap.conf b/bootstrap.conf index 0251819..185d5d4 100644 --- a/bootstra

bug#60326: [COMMITTED 4/8] maint: stop using obsolete stdnoreturn module

* bootstrap.conf (gnulib_modules): Remove stdnoreturn. * gzip.h: Do not include stdnoreturn.h. All uses of noreturn replaced by _Noreturn, at start of declaration for benefit of C23. * lib/.gitignore, m4/.gitignore: Remove names of stdnoreturn-related files. --- bootstrap.conf | 1 - gzip.c

bug#60326: [COMMITTED 6/8] maint: port function definitions to C23

C23 does not allow K&R style function definitions. Use protyped definitions. However, don't bother with (void) in function definitions since C23 prefers (); so prefer () to (void) as this will work with older compilers anyway. --- NEWS | 3 ++ bits.c | 37 --

bug#60326: [COMMITTED 8/8] gzip: port alignas usage to C23

* gzip.c (BUFFER_ALIGNED): Do not depend on __alignas_is_defined as that has been removed from C23. --- NEWS | 2 +- gzip.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/NEWS b/NEWS index 918fcf2..f2ea30e 100644 --- a/NEWS +++ b/NEWS @@ -9,7 +9,7 @@ GNU gzip NEWS

bug#60326: [COMMITTED 7/8] gzip: local → static

* gzip.h (local): Remove. All uses replaced by ‘static’. Previously, the source code was inconsistent about using ‘local’ vs ‘static’ even before the recent changes, and ‘local’ was more trouble than it was worth. --- bits.c| 2 +- deflate.c | 29 + gzip.c| 66 +++

bug#60326: [COMMITTED 5/8] maint: stop using obsolete dosname module

* bootstrap.conf (gnulib_modules): Replace dosname with filename. * gzip.c: Include filename.h, not dosname.h. * lib/.gitignore: Remove name of dosname.h. --- bootstrap.conf | 2 +- gzip.c | 2 +- lib/.gitignore | 1 - 3 files changed, 2 insertions(+), 3 deletions(-) diff --git a/bootstra

bug#60326: [COMMITTED 1/8] build: update gnulib submodule to latest

--- gnulib | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gnulib b/gnulib index fc555c0..758fab7 16 --- a/gnulib +++ b/gnulib @@ -1 +1 @@ -Subproject commit fc555c0a4bf23b3418e0e9cc3a0800172b716b90 +Subproject commit 758fab78eaa325ee0f84a277892d3da55e2370c3 -- 2.38.1

bug#60327: [COMMITTED 2/8] maint: update .gitignore to match Gnulib changes

--- lib/.gitignore | 5 +++-- m4/.gitignore | 5 +++-- 2 files changed, 6 insertions(+), 4 deletions(-) diff --git a/lib/.gitignore b/lib/.gitignore index 151d30f..474a6a9 100644 --- a/lib/.gitignore +++ b/lib/.gitignore @@ -6,6 +6,7 @@ /alloca.in.h /arg-nonnull.h /asnprintf.c +/assert.in.h

bug#56399: Problem building in windows; base, out_waiting

On 7/5/22 07:49, Bloom-Scheff, James L. [US-US] [NON-EMP] via GNU gzip discussion and bug reports. wrote: I am trying to use zlib in windows with visual studio 2019 and 32 bits. This was sent to the wrong mailing list, I think, as gzip and zlib are different projects.

bug#56247: inflate fails to reject invalid distance

From: Paul Eggert Date: Tue, 28 Jun 2022 22:30:08 -0500 Subject: [PATCH 1/2] gzip: detect invalid input Problem reported by Young Mo Kang and fix from Mark Adler (Bug#56247). * inflate.c: Include stdbool.h. (fresh): New static var. * inflate.c (flush_output): Clear it. (inflate): Set it. (inflate_

bug#56247: inflate fails to reject invalid distance

On 6/26/22 22:21, Young Mo Kang wrote: I believe GNU gzip also needs to reject this file, since the file is not a valid deflate format. gzip is compatible with pigz here. It's not clear to me that gzip should be pedantic and reject input that does not strictly conform to RFC 1952. I'll cc t

bug#56090: gzexe make check fail

On 6/19/22 02:56, Adi Gal via GNU gzip discussion and bug reports. wrote: I'm trying to compile gzip-1.9-13.el8_5. That build fails due to a "Hello world" test that is not in GNU gzip proper, so this isn't the right place to report the bug. If you do report it downstream my guess is that they

bug#30029: gzip-1.9 released [stable]

On 4/10/22 11:27, Andreas Schwab wrote: AC_PROG_GREP +AC_CHECK_PROG([LESS], [less], [less]) +AM_CONDITIONAL([LESS], [test "$LESS"]) >> ... This check is bogus. It tests the build environment, which has nothing to do with the host environment. In other words, it's like AC_PROG_GREP. Two wro

bug#30029: gzip-1.9 released [stable]

On 4/10/22 04:08, Andreas Schwab wrote: On Mär 31 2022, Paul Eggert wrote: ... AC_PROG_GREP +AC_CHECK_PROG([LESS], [less], [less]) +AM_CONDITIONAL([LESS], [test "$LESS"]) >> ... This check is bogus. It tests the build environment, which has nothing to do with the host e

bug#54759: Compile error on macOS w/ gcc

Thanks for the bug report. Please try gzip 1.12, released today. It has bug fixes (inherited from Gnulib) in the area you reported, and should build on macOS with GCC. Thanks.

bug#54778: copyright dates in gzip, zgrep etc. --version output

e syntax-check' to try to catch this issue better next time.From 9ab26eaf47092530508269a4d1be0d4e3574e1d6 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Thu, 7 Apr 2022 15:49:26 -0700 Subject: [PATCH] maint: update --version copyright dates MIME-Version: 1.0 Content-Type: text/plain;

bug#31280: zgrep foo binaryfilepath says "Binary file (standard input) matches"

Thanks for your bug report. This bug should be fixed in gzip 1.12, released today. The bug fix is here: https://git.savannah.gnu.org/cgit/gzip.git/commit/?id=9d3248751178939713a39115cf68ec8a11506cc9

bug#42402: Enhancement request re zcat with empty files

I am asking for an enhancement to zcat, that it should silently ignore empty files, either always, or (if that conflicts with POSIX or some other standard), by a command line option. zcat -f does what you're asking for. For example: $ touch empty $ echo something | gzip >abc.gz $ zcat -f * som

bug#16876: Zutils vs single compressor utilities

On 2/25/14 11:40, Paul Eggert wrote: On 02/25/2014 01:47 AM, Dagobert Michelsen wrote: Shouldn’t the transformation be applied to all occurrences? Yes, I think it should. After eight years I got around to implementing this (since nobody else wanted to :-) and installed the attached

bug#43584: [PATCH 1/4] Update .gitignore files

Thanks, I think we've added those .gitignore entries to gzip's development version now. Closing the bug report.

bug#16951: zless error under ulimit -v

On 3/6/14 17:39, Paul Eggert wrote: You can reproduce the 'less' problem ... I followed up this old Gzip bug report by writing a proposed patch for 'less' and filing a 'less' bug report here: https://github.com/gwsw/less/issues/258

bug#20453: Building on AIX 7.1 with GCC

On 4/28/15 19:25, Sevan Janiyan wrote: Just ran into an issue which affects gzip, gettext & tar on AIX. Thanks for reporting that seven years ago. I just now tried building bleeding-edge gzip and gettext 0.21 on AIX 7.1 with xlc, and it worked for me. gzip no longer uses quotearg, and gett

bug#23770: Cannot open file gzipped on Android in OSX

This is evidently a problem with the way you're using adb; it's not a gzip bug. adb will sometimes convert LF to CRLF and vice versa, which is not something you can do to a gzipped file. For help on that topic, please consult an adb expert. Closing this (old) gzip bug report.

bug#24559: [Documentation] man page inconstency

2001 From: Paul Eggert Date: Fri, 1 Apr 2022 09:46:23 -0700 Subject: [PATCH] doc: improve doc for saved timestamps etc. MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Problem reported by Carpe Sébastien (Bug#24559). --- doc/gzip.texi | 18

bug#25633: porting gzip to Visual Studio 2015 failed due to redesign of CRT

As near as I can tell, the issues in this circa-2017 bug report were either resolved or are obsolete now so I'm closing the bug report. If I'm wrong, please feel free to file a fresh bug report. Thanks.

bug#29268: gzip-1.8.41 test results on Mac OS X/PowerPC

the way, I just now tried bleeding-edge gzip on macOS 12.1 (Apple M1) and found one portability glitch, which I fixed by installing the attached into gzip.From 2532f0a0d464fa1d0845a74789cb6859e4086021 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Thu, 31 Mar 2022 17:15:17 -0700 Subject: [PATCH] t

bug#30029: gzip-1.9 released [stable]

t gzip. [1]: https://www.gnu.org/software/libc/manual/html_node/64_002dbit-time-symbol-handling.html [2]: https://www.gnu.org/software/gnulib/manual/html_node/Avoiding-the-year-2038-problem.htmlFrom 2fa0edbe051634f33687572c68fefc150ca3d499 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Thu, 31

bug#30597: Bug: error messages from gunzip

When running gunzip /nonexistent/*gz, the error message from gunzip is very misleading: gzip: /nonexistent/*gz.gz: No such file or directory It's misleadng in two ways: 1. it refers to gzip, when I was running gunzip Yes, gunzip merely calls "gzip -d", so the message is coming from from gzi

  1   2   3   4   5   6   >