12 ms·

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 rewrit

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.

dikaiosune 10y ago
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.
- briansmith 10y ago
  > 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 https://github.com/briansmith/ring
  - dikaiosune 10y ago
    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.
    - spc476 10y ago
      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).
      - strcat 10y ago
        Some symbols are. Not all.
  - marcoperaza 10y ago
    Yes, but you have to be careful to ensure that no two functions are dependent on each other.
posborne 10y ago
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 https://github.com/nix-rust/nix

dikaiosune 10y ago

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.

briansmith 10y ago
> 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 https://github.com/briansmith/ring
- dikaiosune 10y ago
  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.
  - spc476 10y ago
    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).
    - strcat 10y ago
      Some symbols are. Not all.
- marcoperaza 10y ago
  Yes, but you have to be careful to ensure that no two functions are dependent on each other.

posborne 10y ago

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 https://github.com/nix-rust/nix