Not a Linux distro, but FreeBSD uses Clang.
And Android uses Clang for its Linux kernel.
-fbounds-safety is not yet available in upstream Clang though:
NOTE: This is a design document and the feature is not available for users yet.
HN user
Not a Linux distro, but FreeBSD uses Clang.
And Android uses Clang for its Linux kernel.
-fbounds-safety is not yet available in upstream Clang though:
NOTE: This is a design document and the feature is not available for users yet.
The extension is for hardening legacy C code without breaking ABI.
Though the encoder deciding to repeat those Ts doesn't make much sense, shouldn't this be compressed to literal("TOBEORNOT") copy(6,9) copy(9,15)?
IIRC zlib won't consider matches at offset 0: https://github.com/madler/zlib/blob/5a82f71ed1dfc0bec044d970...
Looks like a code block didn't get closed properly
This seems to have been fixed now.
I think that was Shopify: https://x.com/tobi/status/1909231499448401946
Is there a way to just download an Android SDK?
Yes, you can just grab the zip files. For example like this: https://www.hanshq.net/command-line-android.html#sdk
Here's an example for x86: https://www.hanshq.net/ones-and-zeros.html
I think it's a Bay Area thing.
Google's {First 10-digit Prime in Consecutive Digits of e}.com ad is a classic in this genre (https://www.hanshq.net/eprime.html)
They use Swish: https://sverigesradio.se/artikel/hundreds-of-suspected-cocai...
From the article:
In 2022, there were 90 explosions and 101 cases of attempted bombings or preparations for bombings in Sweden, according to police data. As of 15 August this year, 109 explosions had been recorded.
Same for Othello: https://www.hanshq.net/othello.html#bitboards
V8 uses __builtin_assume_aligned to tell the compiler that the base address it uses for pointer compression is 4GB-aligned: https://source.chromium.org/chromium/chromium/src/+/main:v8/...
I'm never quite sure about the state of zlib. There are commits going in [0] but at the same time pull requests with fixes aren't seeing much traction (e.g. [1]).
Optimization work happens in forks like Intel's [2], Cloudflare's [3], and Chromium's [4], the latter of which also has a lot of added tests and fuzzers [5]. And there's zlib-ng [6] which tries to create a home for many of the improvements, but is at the same time yet another fork.
[0] https://github.com/madler/zlib/commits/develop
[1] https://github.com/madler/zlib/pull/525
[2] https://github.com/jtkukunas/zlib
[3] https://github.com/cloudflare/zlib
[4] https://source.chromium.org/chromium/chromium/src/+/main:thi...
[5] https://source.chromium.org/chromium/chromium/src/+/main:thi...
[6] https://github.com/zlib-ng/zlib-ng
(edit: line breaks)
I think it's the article that's confused, or being a bit careless with the details.
Like you say, Deflate is based on LZ77, and I think it's not just for patent reasons but because it's a nice algorithm. More modern algorithms like LZMA is also LZ77 based.
Shrink is LZW, Implode is LZ77 + Shannon-Fano/Huffman. See https://www.hanshq.net/zip2.html
I had not seen that GMP reimplementation before, but it looks very readable. Thanks!
I used the Möller & Granlund paper for a portable implementation of 2-by-1 division [1], and on my machine (which is admittedly not exactly new) it runs much faster than the DIV instruction.
Thanks for the link! I started watching and this looks like an interesting lecture series. (The book looks interesting too.)
https://www.akkadia.org/drepper/tls.pdf is also a great write-up
I've never open sourced it though because I guess it's a bit of a grey area - the sites want you to go to the full URL so they can show you ads etc
Another reason, which I think is fair, is that with full articles in the RSS feed, the feed can quickly become a fairly large chunk of data.
One big part about your post is about streaming. I don't think the ZIP format was ever designed for streaming, and there are no claims about streaming in the original app notes. Actually, the wording about streaming you refer to were only added to the app note last year, and as you rightly point out, it's not guaranteed to work.
I've been trying to figure out where the first z comes from. At least I tend to think "z" is for compression because of ZIP, but it predates that.
.Z was used for compress(1), probably because pack(1) used .z, but where did that come from?
My best theory is that it's from Steve Zucker who wrote pack(1) at RAND. There were other versions of pack(1) too, but if his was the first, it seems possible that he choose the z extension for Zucker.
Does anyone have more info or other theories?
This is wonderful. Thanks for sharing!
Thanks for sharing! That whole article is wonderful.
You may also want to try the GN build: https://github.com/llvm/llvm-project/blob/master/llvm/utils/...
I submitted the announcement email because it links to release notes from all the projects (i.e. Clang, LLD, Flang, etc.) and not just the main LLVM ones.
(Also it seems the version number changed from 11.0.0 to 11.0?)
Can't wait to read that book!
Chrome M64 was the first shipping version built with Clang on Windows: http://web.archive.org/web/20200125010517/http://blog.llvm.o...
Not supporting streaming decompression simplifies the implementation a lot, which seems to fit well with the project's goals (hwzip does this too: https://www.hanshq.net/zip.html).
It should still work with large files on systems where they can be memory mapped.
No problem, I was just wondering if I missed something. Filed https://bugs.llvm.org/show_bug.cgi?id=46194
OSSFuzz is an automated system.