Expose API availability to downstream crates

[kamalmarhubi]

Lots of system APIs get new flag values added over time, or have other changes. Also, some APIs are available on many but not all platforms. It would be ideal if libc made this available downstream in a better way than having undefined items. This would allow progressive enhancement based on the target system's capabilities.

My main idea is to provide a library that downstream projects can use in their build scripts. The library would make it easy to define features that can be used in cfg attributes in the downstream project.

Examples

The tempfile crate could use open(2) with O_TMPFILE on Linux 3.11+ where it exists, and fall back to mkstemp(3) + unlink(2) where it doesn't.

A server might use vmsplice(2) on Linux to avoid copies, with write(2) or send(2) as a fallback.

This could be provided by a third party crate as the maintenance burden is fairly high, and the testing story would be a bit rough. Any thoughts?

[alexcrichton]

The intention of the libc crate was basically to just provide the most up-to-date version of APIs that there are with the assumption that the old APIs are always binary compatible with the new ones (which they typically are). In terms of any fallback implementations, that was going to be left up to downstream crates. Downstream authors need to be vigilant to not use APIs that aren't available on a platform they're shipping on.

We could perhaps add some features to libc which can be subtracted to remove swaths of the API, but that probably won't work out well in practice.

Basically, in my opinion, dynamic detection of what APIs are available at runtime shouldn't be done by libc. All libc is doing is defining what the APIs would be if they're there.

[kamalmarhubi]

Downstream authors need to be vigilant to not use APIs that aren't available on a platform they're shipping on.

I was thinking of helping them (myself included), but I definitely get that this doesn't really fall under rust-lang/libc's responsibilities.

We could perhaps add some features to libc which can be subtracted to remove swaths of the API, but that probably won't work out well in practice.

Yeah I don't think that's the way to go either.

All libc is doing is defining what the APIs would be if they're there.

👍 this makes sense.

[kamalmarhubi]

Basically, in my opinion, dynamic detection of what APIs are available at runtime shouldn't be done by libc.

Although I meant detection at compile time based on the target, but I think you're still right about it not belonging in libc.

[alexcrichton]

I will also say, however, that I'm particularly interested in this. This sort of functionality is likely desired by many projects, and we've already got prototypes in the standard library, for example. It may make sense for this to be outside the repository as it's also relevant for winapi APIs as opposed to just libc apis as well, however.

[kamalmarhubi]

@alexcrichton good to know it's of interest! I'll let the idea bubble in the back of my mind for a bit, and maybe throw up a crate and ping you to look at it at some point in the indefinite future. :-)