sunfishcode / c-ward Goto Github PK

I run into mismatches types because c-scape:src/fs/xattr.rs has READ_BUFFER as [u8] and passes it to rustix::fs::listxattr which expects [i8] (actually c::c_char).
That happens with rustix 0.38.34 and Eyra from main. Using the nightly-2024-04-21 from the Eyra toolchain didn't help.
Other functions such as fgetxattr in rustix expect u8 and if rustix is right if might make sense to add a second READ_BUFFER definition in c-scape that uses i8, or?

We should implement the ptsname and ptsname_r functions, in c-scape/src/termios_/mod.rs, and remove them from c-scape/src/todo.rs.

Rustix has a ptsname function, so what's needed for c-scape is to adapt that function to the C API.

I've labeled this a "good first issue", though that's admittedly relative. It requires familiarity with C strings, raw pointers, and static buffers.

We should implement the fchownat function, in a new c-scape/src/fs/chown.rs, and remove it from c-scape/src/todo.rs.

Rustix has a chownat function (which is rustix's name for fchownat) so what's needed for c-scape is to adapt that function to the C API.

Many C projects depend on this. For example lua and musl's dynamic linker. And (when __builtin_setjmp/__builtin_longjmp support is not detected) Wasmtime depends on it too.

Bootloader -> kernel -> userspace where init is... Busybox shell?

So I guess this becomes, can the kernel and Busybox compile with this? I think you can build kernel with musl (I might have it wrong that you need libc to compile the kernel at all)

Hello!

I've been trying to compile a toy miniquad project using both eyra and mustang, but unfortunately in both instances I got the same errors:

error[E0432]: unresolved import `core::ptr::invalid_mut`
 --> /home/rice7th/.cargo/registry/src/index.crates.io-6f17d22bba15001f/c-scape-0.15.40/src/brk.rs:2:17
  |
2 | use core::ptr::{invalid_mut, null_mut};
  |                 ^^^^^^^^^^^ no `invalid_mut` in `ptr`

error[E0432]: unresolved import `core::ptr::invalid_mut`
 --> /home/rice7th/.cargo/registry/src/index.crates.io-6f17d22bba15001f/c-scape-0.15.40/src/syscall.rs:5:5
  |
5 | use core::ptr::invalid_mut;
  |     ^^^^^^^^^^^^^^^^^^^^^^ no `invalid_mut` in `ptr`

error[E0425]: cannot find function `invalid_mut` in module `ptr`
   --> /home/rice7th/.cargo/registry/src/index.crates.io-6f17d22bba15001f/c-scape-0.15.40/src/process_.rs:192:32
    |
192 |         libc::AT_HWCAP => ptr::invalid_mut(rustix::param::linux_hwcap().0),
    |                                ^^^^^^^^^^^ not found in `ptr`

error[E0425]: cannot find function `invalid_mut` in module `ptr`
   --> /home/rice7th/.cargo/registry/src/index.crates.io-6f17d22bba15001f/c-scape-0.15.40/src/process_.rs:193:33
    |
193 |         libc::AT_HWCAP2 => ptr::invalid_mut(rustix::param::linux_hwcap().1),
    |                                 ^^^^^^^^^^^ not found in `ptr`

Some errors have detailed explanations: E0425, E0432.
For more information about an error, try `rustc --explain E0425`.
error: could not compile `c-scape` (lib) due to 4 previous errors

Everything else compiles just fine.

Using the latest eyra/mustang and the latest nightly. Even adding the #![feature(strict_provenance)] feature gate does nothing.

According to the strverscmp documentation, 000 is ordered before 00, which means that strverscmp("000", "00") should return a negative value, however it currently returns a positive value.

Specifically, running this:

fn main() {
    extern "C" {
        fn strverscmp(a: *const libc::c_char, b: *const libc::c_char) -> libc::c_int;
    }
    unsafe {
        dbg!(strverscmp("000\0".as_ptr().cast(), "00\0".as_ptr().cast()));
    }
}

prints the value 48.

@KGrewal1

Since rust-lang/rust#117957 - CI started to show error(it worked before):

  = note: /usr/bin/ld: /home/runner/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-6af6cb20bb87a7a8.rlib(std-6af6cb20bb87a7a8.std.5f6dbc7992e36f36-cgu.0.rcgu.o): in function `std::sys::unix::process::process_inner::Process::try_wait':
          /rustc/2f8d81f9dbac6b8df982199f69da04a4c8357227/library/std/src/sys/unix/process/process_unix.rs:872: undefined reference to `waitid'
          /usr/bin/ld: /home/runner/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-6af6cb20bb87a7a8.rlib(std-6af6cb20bb87a7a8.std.5f6dbc7992e36f36-cgu.0.rcgu.o): in function `std::sys::unix::process::process_inner::Process::wait::{{closure}}':
          /rustc/2f8d81f9dbac6b8df982199f69da04a4c8357227/library/std/src/sys/unix/process/process_unix.rs:851: undefined reference to `waitid'
          /usr/bin/ld: /home/runner/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-6af6cb20bb87a7a8.rlib(std-6af6cb20bb87a7a8.std.5f6dbc7992e36f36-cgu.0.rcgu.o): in function `std::sys::unix::cvt':
          /rustc/2f8d81f9dbac6b8df982199f69da04a4c8357227/library/std/src/sys/unix/mod.rs:(.text._ZN3std3sys4unix7process13process_inner7Process4wait17h18922f9e5187f71aE+0x9d): undefined reference to `waitid'
          collect2: error: ld returned 1 exit status

On one hand, Eyra has almost no code; it's just dependencies on other crates. It doesn't really need its own repo.

On the other, Eyra is an outward-facing personality, with c-gull/c-scape as somewhat encapsulated implementation details, so it might be nice to let Eyra have its own place.

Or maybe Eyra should be merged back into Mustang, now that they're both very close to the same thing.

Or maybe this is the time to introduce a new github organization, as @notgull suggested, where Origin, c-ward, Mustang, Eyra, and some of the smaller helper crates can all live, under an umbrella.

Hello @sunfishcode.

Thanks for working on this project!

Is it possible to add a list of all implemented and unimplemented libc functions? I think it will make it easier for people to see if c-scape supports the ones that they need. It should also allow to easily calculate the percentage and maybe graph it over time.

It's just a suggestion. Thanks.

The code that uses getent to interact with NSS is probably useful in contexts outside of eyra as well. It would be useful for implementing libc calls like, say, getpwuid_r.

The coexist-with-libc mode seems dubious for the vast majority of functions - anything that touches a shared header or struct (say, FILE or pthread_mutex_t) is likely to run into severe issues if it is used as a parameter in a function we do not implement.

In addition, it also seems not useful for the actual use cases this library supports - llvm-libc's version which replaces only the functions without shared structs (say FD functions or string functions) is only really useful because it's in C, Rust code likely uses its own.