Hacker News Reader

Comment by dikaiosune | Hacker News Reader

This is a hobby project for my own edification, and maybe maybe to eventually show Rust's suitability for this kind of work. While I appreciate that the semantics of returning usize::MAX aren't correct, I'm also not an expert on C standard library implementations. Just a hobbyist writing a little bit about something I'm trying out.

Potentially relevant is this section of the repo's README:

https://github.com/dikaiosune/rusl#goals-and-non-goals

EDIT: After a suggestion in a sibling here, here's a version which neither explicitly aborts (musl doesn't do abort or unreachable), nor uses an explicit return of usize::MAX:

https://is.gd/lck8c7

It doesn't autovectorize, but I suspect that with some work I could maybe convince LLVM to do so.

View on HN

IMO, it would be more interesting to see it done top-down, instead of bottom-up. That is, instead of starting with rewriting `strlen`, why not start with rewriting `getaddrinfo`? That would be a very interesting project because you could write `getaddrinfo` with a safe Rust API (i.e. one that doesn't require using `unsafe` to call it), and then wrap it in an `unsafe` function that exports the unsafe C `getaddrinfo` function. This could arguably then be an improvement on the musl code.

I think it very well could be.

However, I would imagine (not having looked at the problem in depth) that one would want to be able to use things like Vec<T> or CString from the Rust standard library when implementing a DNS resolver. Since the Rust standard library depends on libc, I'm not sure how one would properly allow the Rust symbols to replace the linked-in libc symbols while still depending on the rest of libc. Maybe it's not an issue? Maybe there's some magic which could be done?

Nonetheless, I mostly started doing this to see if it could be done, not to prove any point (although I'd love it if a point is proven along the way), so a bottom-up approach with #![no_std] was the easiest way to prevent any sort of cyclic dependencies and/or linker issues.

> Since the Rust standard library depends on libc, I'm not sure how one would properly allow the Rust symbols to replace the linked-in libc symbols while still depending on the rest of libc. Maybe it's not an issue? Maybe there's some magic which could be done?

Static libraries can have circular dependencies like that. For example, in ring[1] I have C code in one static library, which calls some Rust functions in my Rust code. And, that Rust code calls functions in the C static library. The linker...links them together.

[1] https://github.com/briansmith/ring

Circular dependencies are different than duplicate symbols, though, yes? Anyways, my point is not that it's impossible, but that I'm already working at the edge of my knowledge, and I picked the lowest-risk/smallest-chunk pieces of work to get started.

On Linux, the symbols in glibc are marked as "weak"---that is, if the symbol "malloc" isn't found in another object file, then the one in glibc is used. It's that way so that users can override system provided functions (non-"weak" symbols that are duplicated are considered an error).

Some symbols are. Not all.

Yes, but you have to be careful to ensure that no two functions are dependent on each other.

For safe, well-reviewed wrappers around libc (a different problem, but one which is more realistic to solve), I would encourage you to check out the nix crate (I am a maintainer -- the original author was Carl Lerche). It doesn't look like we have a wrapper for getaddrinfo currently, but it is something I think we would welcome.

https://github.com/nix-rust/nix

> musl doesn't do abort or unreachable

musl doesn't do dlclose either --- doesn't mean it's a bad idea. Let's not confuse glibc being bad with musl being good.

The goal of the project is to reimplement musl in Rust. It's not a value judgement about musl, glibc, or any alternative implementation. It's about managing the scope of a hobby project the goal of which is to learn more, not to necessarily do any better than those who've come before.

Reply on news.ycombinator.com