make c wrapper no_std about ttf-parser HOT 16 CLOSED

can c-api also become no_std

Not sure if it's possible. Will take a look.

You should use dynamic linking. Static linking is kinda broken in Rust. At least for me. That's why c-api doesn't build static at all. I guess it should be fixed in meson too.

from ttf-parser.

Not sure if it's possible. Will take a look.

Thank you so much. I will also.

You should use dynamic linking. Static linking is kinda broken in Rust. At least for me. That's why c-api doesn't build static at all. I guess it should be fixed in meson too.

Apparently I were able to somehow maybe at some limited cases, static linking is very convenient, am imagining some C library embeds a rust library and itself can be static linked to another library easily.

from ttf-parser.

No, static linking via C API in rust is very troublesome. You should always use dynamic one.

from ttf-parser.

Yes, no_std no possible due to std::panic::catch_unwind. So meson should be changed to cdylib.

Afaik, the problem with static linking is that rust links its own std with specific system libraries, which can cause conflicts during linking.

Personally, I always use dynamic linking for C API.

from ttf-parser.

Rust claims able to run on bare metal hardware but doesn't support static linking a c-api, that's very unfortunate :/ I wished it had some solution, maybe we should bring this to the rust development community and maybe I'm getting it also as a dylib also and I'm unaware of it?

from ttf-parser.

It does support static linking. The problem is that you have to provide required libraries manually. pthread in your case.

dylib is a Rust dynamic library. You need cdylib, which is a C dynamic library.

from ttf-parser.

Oh I see, so its use is on catch_unwind, This method invokes a lot of parsing, so let's catch any panics just in case., is there someway to avoid panics from the beginning somehow? And is there anything worth to investigate? rust-lang/rfcs#2810 is related I guess.

from ttf-parser.

avoid panics from the beginning

It's one of the goals. But it will take a lot of time. Weeks.

from ttf-parser.

It's one of the goals. But it will take a lot of time. Weeks.

Thank you so much, so there is a hope which is great! I will also try so to improve my Rust experience. Thanks

from ttf-parser.

Yes, no_std no possible due to std::panic::catch_unwind. So meson should be changed to cdylib.

As an alternative to catch_unwind, you can use a drop-then-abort guard to prevent panics from unwinding into other code. This is no_std.

from ttf-parser.

@notgull can you elaborate?

from ttf-parser.

I think what he means is something like:

struct DropAbortGuard;

impl DropAbortGuard {
    fn new() -> Self {
        Self
    }
    
    fn end(self) {
        core::mem::forget(self); // Ensures drop doesn't run for self
    }
}

impl Drop for DropAbortGuard {
    fn drop(&mut self) {
        panic!(); // Panic while panicing becomes an abort
    }
}

let guard = DropAbortGuard::new();

some_code_that_might_panic();

guard.end();

It's not pretty, but it seems to work.

from ttf-parser.

Yeah, you can find an example of this pattern here. Since you don't expect the code to panic anyways it should be a good fit

from ttf-parser.

Hmm... it simply replaces panic with abort, which is not what I want.
The whole point behind using catch_unwind is that I cannot statically prove that ttf-parser will not panic. Sadly, this is the current Rust limitation. We need language-level #[no-panic] attribute first.

from ttf-parser.

Hmm... it simply replaces panic with abort, which is not what I want.

Are you sure? In your README, you say that any panic is a critical bug. Therefore, I would think that replacing the panic with an snort would be the best option, since unwinding into the C stack frames is unsound behavior.

In fact, I'd say that wrapping every C API function in an abort guard like this is required for soundness. While, in theory, many of the function you use don't panic, there may be devils hidden in those details, and a core dump is preferable to corrupting the stack.

from ttf-parser.

I threat every function as panicking in Rust. Which is true until we get #[no-panic].

In your README, you say that any panic is a critical bug.

It doesn't mean that there are no panics in ttf-parser. ttf-parser is like 15 KLOC. I cannot guarantee anything at this scale.

from ttf-parser.