Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

C API #14

Open
hargoniX opened this issue Mar 14, 2020 · 4 comments
Open

C API #14

hargoniX opened this issue Mar 14, 2020 · 4 comments
Labels
enhancement low Low priority tasks

Comments

@hargoniX
Copy link
Member

It would be nice if we could expose a C API and compile into a static lib so the crate could be linked into already exisitng C programs in order to be used in already existing C applications. This could be especially interesting for once AVR supports lands in rustc, then it could be used in Arduino applications as a safe building stone.

@SkamDart
Copy link

@hargoniX looks like no one has taken a stab at this and I would be interested.
Would you feature flag the C FFI then use something like cbindgen to generate C headers using libc for C types in Rust?

@hargoniX
Copy link
Member Author

hargoniX commented Jul 24, 2020

I would gate it yes, however as of now the public API still requires some alloc (HashSet in specific + some Vecs) so i imagine that might be hard to represent, I got a PR that tries to change that, however I didnt get back to it for quite some while as I've been busy with other things :/

Since its kind of a blocker for you though I'll try to get to it this evening / during the weekend.

Some other API's however shoul mostly be C friendly so you should be good to start off with those why I finish the no_std part.

As for libc, I think that'd be a big no no since we are targeting Embedded here where lots of times no libc is available for use. I could imagine you either working around that by making sure the bindings only expose stuff with C types that are available without C stdlib on a bare metal system...or alternatively handwrite the bindings, I'll leave that up to you!

@SkamDart
Copy link

I was thinking of something like this so glibc is only a dependency if you want to use the c_ffi feature.

[package]
name = "nmea"
version = "0.0.9"
authors = ["Felix Obenhuber <felix@obenhuber.de>", "Evgeniy A. Dushistov <dushistov@mail.ru>"]
description = "Simple NMEA 0183 parser"
license = "Apache-2.0"
keywords = ["NMEA", "gps", "glonass", "coordinate", "position"]
repository = "https://github.com/AeroRust/nmea"
documentation = "https://docs.rs/nmea/"
readme = "README.md"
edition = "2018"

[dependencies]
arrayvec = "0.5"
chrono = "0.4"
libc = { version = "0.2.73", optional = true }
nom = "5"

[build-dependencies]
cbindgen = { version = "0.14.3", optional = true }

[features]
c_ffi = ["libc", "cbindgen"]


[dev-dependencies]
quickcheck = "0.9"
approx = "0.3"

@hargoniX
Copy link
Member Author

I'd say we should restrict ourselves to a set of types that are available when using libc in no_std mode (according to their README that's a thing), after all this crate should be usable in environments like Arduino or embedded C running on Cortex-M (or R) etc. which probably only have a subset of C types (and definitely no rust std library). These projects however might want to have a lib that provides them memory save parsing of NMEA packets since C is not very good at parsing (living example, libxml2 fixing memory bugs on a weekly basis)

@elpiel elpiel added low Low priority tasks and removed help wanted labels Sep 17, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement low Low priority tasks
Projects
None yet
Development

No branches or pull requests

3 participants