LZMAT
ZLib
Our great sponsors
| LZMAT | ZLib | |
|---|---|---|
| 0 | 41 | |
| 7 | 4,426 | |
| - | - | |
| 0.0 | 0.0 | |
| about 7 years ago | 4 days ago | |
| C | C | |
| - | GNU General Public License v3.0 or later |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
LZMAT
We haven't tracked posts mentioning LZMAT yet.
Tracking mentions began in Dec 2020.
ZLib
-
Quite OK Image is now my favorite asset format
A minimal viable Deflate decompressor is not exactly complex[1], although slower than mainline zlib.
-
Zlib alternatives?
ZLibrary not zlib for anyone worried about archiving algorithms. https://zlib.net/ and all the Linux repositories are safe (AFAIK).
-
Save File Corruption fix? PLEASE HELP
>The following is my educated guess at what to do next and I am a week-end warrior programmer at best. If someone with more experience comments, I would listen to them over me< If you have no programming experience, this may be a lost cause. It looks like the save file has a header area followed by a list of "zlib" compressed chunks. zlib.net may have a program that can open the save file and let you see the raw information inside it. Something after the header is garbled and it is preventing Save-Editors from decompressing that chunk OR from parsing what is inside of it. If you are lucky, the garbled bit will jump out at you and you can repair it.
-
Zlib Critical Vulnerability
These appears to be the relevant changes:
2022-07-30: https://github.com/madler/zlib/commit/eff308af425b67093bab25...
2022-08-08: https://github.com/madler/zlib/commit/1eb7682f845ac9e9bf9ae3...
The second commit definitely fixed a null pointer dereference, I am not sure if the CVE is referencing something else that was fixed by the first commit.
-
Gzip and Brotli Compression Level Estimator
It is actually possible to estimate the compression level without actually compressing everything again, because different levels use different strategies which can be identified in some cases. zlib in particular has three strategies [1] and preflate [2] leverages this to store the deflate stream reconstruction data without much bits.
[1] https://github.com/madler/zlib/blob/21767c6/deflate.c#L134-L...
[2] https://github.com/deus-libri/preflate/blob/master/preflate_...
-
What does it take to be a good programmer?
It's still a heap of old school C spaghetti https://github.com/madler/zlib/commit/eff308af425b67093bab25...
-
Faster zlib/DEFLATE decompression on the Apple M1 (and x86)
The non-forked zlib hasn't been accepting optimisations: https://github.com/madler/zlib/issues/346
Hopefully changes will be merged from my obscure private fork into four other obscure private forks (zlib-chromium (https://crbug.com/1354990), zlib-ng, zlib-cloudflare, and the one I personally care about, which doesn't take pull requests, zlib-apple), and possibly incorporated into libdeflate. That's the point of the blog post - to help maintainers understand the changes.
-
Re: Zlib memory corruption on deflate (i.e. compress)
This seems to be a minor bug, in that it is only triggered using unusual (and rather unlikely) deflate parameters.
But, looking into this bug, I was sort-of interested to see how it was handled. The change log for 1.2.12 (2022-03-27) indicates the issue was resolved ("Fix a bug that can crash deflate on some input when using Z_FIXED"). Yet, in what seems to be the canonical Zlib repository (https://github.com/madler/zlib), I was unable to find a corresponding commit.
None of commits this year (7, so not too hard to review) seem to be particularity meaningful changes, and in particular yesterday's 'zlib 1.2.12' commit seems to only consist of version/copyright updates.
So, does anyone have any idea where to find the commits related to the change log entry? (Note that I'm not disputing the issue is actually fixed, I'm just trying to improve my Github reading skills...)
- Ask HN: Single person creations that have stood the test of time
What are some alternatives?
zstd - Zstandard - Fast real-time compression algorithm
Onion - C library to create simple HTTP servers and Web Applications.
LZ4 - Extremely Fast Compression algorithm
LZMA - (Unofficial) Git mirror of LZMA SDK releases
Snappy - A fast compressor/decompressor
brotli - Brotli compression format
Minizip-ng - Fork of the popular zip manipulation library found in the zlib distribution.
zlib-ng - zlib replacement with optimizations for "next generation" systems.
libarchive - Multi-format archive and compression library
LZFSE - LZFSE compression library and command line tool
OpenSSL - TLS/SSL and crypto library
zlib-ng - zlib replacement with optimizations for "next generation" systems. [Moved to: https://github.com/zlib-ng/zlib-ng]