Consider removing libc dependency to build ~7x faster

[kettle11]

I experimented with removing libc and using just the parts needed of libc needed for this crate. I tested out the changes on this fork: https://github.com/kettle11/malloc_buf

I replaced extern crate libc; with the following (which is based upon the libc crate):

mod libc {
    #[repr(u8)]
    #[allow(missing_copy_implementations)]
    #[allow(missing_debug_implementations)]
    pub enum c_void {
        #[doc(hidden)]
        __variant1,
        #[doc(hidden)]
        __variant2,
    }

    pub type c_char = i8;
    pub type size_t = usize;

    extern "C" {
        pub fn free(ptr: *mut c_void);
        pub fn malloc(amt: size_t) -> *mut c_void;
        pub fn strlen(cs: *const c_char) -> size_t;
    }
}

On my 2016 Macbook this decreases build times from ~1.72s to ~0.22s.

This just about halves the build times for the objc crate for me. With so many people using your objc / mallof_buf, that time adds up!

[SSheldon]

Appreciate the investigation! I agree building 7x faster sounds pretty nice, but when phrased as saving 1.5 seconds it's a bit less compelling 😛

A couple points:

• libc is a very fundamental dependency, so even if we remove it from malloc_buf, there's a very good chance that someone else in the crate hierarchy is still using it. That means that we won't actually save 1.5 seconds, because libc will still need to be compiled for other crates
• there's subtle complexity to the declarations you've put here. I'm assuming that c_void declaration is correct, but I don't think I would have been able to come up with it on my own, and I'd rather trust someone else in the rust community to write and maintain it for me. For c_char, my immediate question is whether it should be unsigned on any platform; at a glance I can't find anything suggesting it differs, but in working on objc I have run into some fun differences between x86 and arm architectures for iOS. Even if we can confirm all of this, I'm not sure the mental overhead is worth the savings

If we have some wider data showing a significant compile time cost in real-world projects from this, or if we start seeing a trend across the rust ecosystem of moving away from libc, that could make me re-evaluate here. But for now I think keeping the libc dependency is still the solution with the best tradeoffs.

[kettle11]

Sounds good, just wanted to share my findings from this experiment!