Export libc

[lights0123]

This PR exports libc, so that libc can be removed as a dependency for rusb. This is intended to allow for easily replacing this crate while still using rusb on a platform that doesn't have a libc—e.g. WASM. I've written a crate that is ABI- and API-compatible with this crate and libusb that uses WebUSB, but would still like to be able to use rusb and other crates that depend on it. Cargo's patch feature makes that easy, but then it's still necessary to define a separate libc crate to define the few types that it uses.

If this gets merged, I'll send another PR to rusb to not depend on libc any more and only use this crate.

[a1ien]

Hmmmm.... maybe we can entire remove libc as dependency. And use std::os::raw types....

[lights0123]

I thought about that, but timeval, time_t, and suseconds_t are used.

[a1ien]

I think we can define our timeval like this

#[repr(C)]
pub struct timeval {
    pub tv_sec: c_long,
    pub tv_usec: c_long,
}

Where did you find suseconds_t?

[lights0123]

https://github.com/a1ien/rusb/blob/59d9ac6fcfa68c91a4d1e41a0b568293a6d759bb/src/context.rs#L16 (although, that could be written to use as _, but that's generally not preferred)

That's also not portable—Linux and Windows follow that, but macOS defines suseconds_t as an i32 rather than a c_long (which is an i64).

[a1ien]

I like idea about use std::os::raw in rusb crate. And we can add some workaround for timeval. Maybe with some manual implementing timeval as in libc

[lights0123]

Is there anything wrong with depending on libc? Most likely, something else is going to depend on it anyways.

[a1ien]

Is there anything wrong with depending on libc?

No. Just to reduce dependency. And if we could not depend on libc not only in rusb it would be better.