Compiling gzip 1.9 on macOS 10.13.6 using Xcode 10.1 with clang (Apple LLVM
version 10.0.0 (clang-1000.11.45.5)), I get this error after ./configure and
make:
memrchr.c:71:18: error: cast from 'const unsigned char *' to 'const longword *'
(aka 'const unsigned long *') increases required al
This should fix it:
--- a/inflate.c
+++ b/inflate.c
@@ -799,6 +799,11 @@ inflate_dynamic(void)
NEEDBITS((unsigned)bl)
j = (td = tl + ((unsigned)b & m))->b;
DUMPBITS(j)
+if (td->e == 99)/* invalid code */
+{
+ huft_free(tl);
+ return 2;
+}
j = td->v.n;
My clang on macOS doesn’t support it.
> On Nov 30, 2018, at 6:28 AM, Hanno Böck wrote:
>
> On Wed, 28 Nov 2018 21:09:45 +
> "Adler, Mark" wrote:
>
>> However I don’t have a memory sanitizer, so please verify. Thanks.
>
> It's fixed with this pa
This does not appear to be an end-of-line conversion issue. The files you
attached are uuencoded, which would transfer fine with or without end-of-line
conversion. However, when uudecoded they are still not gzip files, and they do
not have any deflate-compressed streams buried within. After deco
Robert,
No, it’s not that the gzip utility implementation is using the wrong size
integer. This is because the gzip utility is using the gzip-format trailer to
guess at the uncompressed length. That trailer has a four-byte length, which is
the uncompressed length of the last member modulo 2^32.
pigz -l doesn’t do that, but pigz -lt does. Since -t has to decode the whole
file, -l combined with it will use that information to give the correct result.
For compatibility, pigz -l still does what gzip does, which is to guess based
on what it finds at the end of the file.
> On Aug 9, 2021, a
gzip -l and pigz -l give the correct answer
nearly all of the time, and is extremely fast. So “-l" still seems useful.
> On Aug 9, 2021, at 2:41 PM, Paul Eggert wrote:
>
> On 8/9/21 8:19 AM, Adler, Mark wrote:
>> pigz -l doesn’t do that, but pigz -lt does. Since -t has
gzip theologians,
Just for information, up to now, pigz would merrily unlink the hard link of the
input file, even if it has other hard links. While I’m not sure I understand
why it shouldn’t do that (that is in fact what you asked it to do), in the
spirit of behaving mostly like gzip, it will
Mr. Wrotycz,
I’m not sure what you mean by “bloated”, but anyway, the current code in zlib
for CRC-32 does not use slice-by-8. It uses braids, which is faster. If there
were going to be a replacement for the software CRC in gzip, it should start
there.
It could also finish there, simply by cop
> And, again, due to level of complexity in the code, I didn't check it. I have
> this quirk that I want to understand stuff I use, here I couldn't so I didn't
> follow.
>
> I will check that braids thing when I find something about it.
The paper on braided CRCs is in the zlib distribution: do
On Mar 14, 2024, at 3:46 PM, wrotycz wrote:
>
>
> Despite that the question is how do I use zlib crc32()? It doesn't give me
> correct result.
>
> My 'rig' is this:
>
> ~~~
> crc = -1
> while (buffer, length = read_data()):
> {
> crc = crcfunc(crc, buffer, length)
> }
> crc = ~crc
> > On Mar 13, 2024, at 6:14 PM, wrotycz < wrotycz@#$%...
I know it's a mail list but I would appreciate to not broadcast my email to
every (spam)bot on the web. Archive is publicly available and easily searchable
by boys, so next time don't quote someone's email in the message.
Alas wrotycz@#$
On Apr 6, 2025, at 10:43 PM, Nicolas Boos via GNU gzip discussion and bug
reports. wrote:
> Will a binary built with an i686 toolchain and a CPU supporting pclmul will
> work from a system without this instruction?
Yes. There is an instruction to check for that instruction. It also checks for
A
Nick,
I think what you mean is when you try the zip and then try to decompress it
with gzip you get that. You can’t get that from zip.
As it happens, earlier today I sent Paul patches for gzip to handle Zip64.
Yes, Info-ZIP’s zip really likes to insert Zip64 fields when it doesn’t need to.
The
Paul,
All looks good. Though for the NEWS I would just say “a well-formed streamed
zip file.” Any streaming zipper could trigger the issue. For example, Info-ZIPs
zip streams a zip file that does not work with 1.14, but does work with the new
patches. I would consider it rather more likely that
Paul,
I see the problem. I’ll fix it.
Mark
> On Jun 15, 2025, at 10:03 AM, Paul Eggert wrote:
>
> 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 repor
So this is an alleged pigz bug being reported? Then why is it being reported on
this gzip bug list? It should be reported instead at
https://github.com/madler/pigz/issues .
Though don’t bother, because this is not a bug in pigz. The problem is with the
“other un/zippers” which per the linked re
On Jun 15, 2025, at 9:05 AM, oset wrote:
I know my Eglish not best, but I wrote it in comprehensive enough manner. You
don't have to hiss, just read it again.
I read it again. It says "Zip created by pigz[1] is deemed to be corrupted …”,
but nowhere in there do you say what exactly is doing the
Paul,
> On Jun 15, 2025, at 9:37 AM, Paul Eggert wrote:
>
> 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 bu
19 matches
Mail list logo
