This PR sacrifices a little bit of type safety in order to build successfully with both old and new versions of libc. I'm not sure if we should merge it, just because I'm not sure if the libc folks are actually planning to release these changes as part of the 0.2 series.

This PR sacrifices a little bit of type safety in order to build successfully with both old and new versions of libc.

Given that the development of libc has been divided into 2 branches:

• 0.2 (the libc-0.2 branch)
• 1.0 (the main branch, previously it was 0.3)

I think we need to choose one to follow, from the tracking issue, there are still a lot of work to do to make libc 1.0 ready so I guess it won't happen in the near future, and it is recommended to file PRs against the libc-0.2 branch if one wants to make the patch available quickly, so we should probably go with 0.2?

However, most PRs are targeting the main branch, i.e., a lot of new APIs will be only available with libc 0.2.x, which makes it really hard to choose...

I'm not sure if we should merge it, just because I'm not sure if the libc folks are actually planning to release these changes as part of the 0.2 series.

These breaking changes are in the main branch, so I guess they won't be included in the future 0.2.x release.