Also being discussed here:
A recurring complaint is the "bespoke hashmap implementation" in the http crate. Is this maybe something that should be remedied?
Now, to be fair, it isn't something that can just be replaced with a libstd HashMap, primarily because it is a MultiMap.
But from a quick glance it does seem to me, that the implementation could probably be made safer and possibly simpler.
I did some comparison of http::HeaderMap
and the safe indexmap
crate. (See this reddit thread for benchmarks and other commentary.) In my opinion, HeaderMap
is already written in a way that is very easy to audit for safety. It is 100% safe Rust except for the iterators, which use raw pointers in a straightforward way.
It would be possible to reduce the number of lines of unsafe code in the iterators (maybe at the expense of some code duplication), but it's pretty common for mutable iterators over custom data structures to require at least some unsafe code.
My own uluru
crate, used in Firefox, needs exactly one line of unsafe Rust for the same reason as HeaderMap
: Both libraries store an index-based linked list in a Vec. Constructing and accessing the list can be done in safe Rust, but a mutable iterator requires unsafe
because its aliasing behavior isn't visible to the compiler (even though it is easily verified by a human).
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.