In general, c_scape doesn't need to be no_std; it just needs to make sure it supports any libc functions that the parts of std it uses use :-). So unless there are other considerations, I suggest removing the default-features = false here.

Right, didn't think that through clearly.

Isn't there the risk of a cyclic dependency between say extern "C" fn memchr and the cpu feature detection code in libstd?

Yes, there is :-). There are risks of cyclic dependencies between core/alloc and c-scape as well; it's the nature of the space c-scape is operating in.

To say a little more here: I guess core doesn't call libc, but AIUI alloc does (by default).

And the other side here is that no_std is really limiting; we don't get useful things like OsStr or CStr or Ipv4Addr or other things, and we have fewer options in terms of third-party crates we can use. And ultimately, the point of mustang is to run on Linux, and sometimes the hoops that no_std makes us jump through aren't meaningful, because we do have an OS. So it comes down to a kind of somewhat-educated guess, that using std will work out well enough to be worth the risks and downsides.