libc: Add fopencookie(3) wrapper around funopen(3)

[cem]

Summary

Given how similar funopen(3) and fopencookie(3) are aside from API, it is
unfortunate that programs that use the latter need ifdefs and slight code
changes to be portable between platforms.

So, adopt the glibc interface.

Yes, BSD had funopen(3) first and glibc decided to do their own thing. I don't
think spite is a good reason not to ease portability, though. Adding the shim
is cheap and doesn't hurt. Finally, with both interfaces we are in good shape
regardless which, if any, interface becomes standard.

[jhb]

Would be nice to fix the funopen callbacks to work with size_t, etc. That's a bit of a harrier mess though one could do it with a newer "version" of funopen() via symver if the API change was considered ok for 11.0 or 12.0.

[cem]

In D6282#133555, @jhb wrote:

Would be nice to fix the funopen callbacks to work with size_t, etc. That's a bit of a harrier mess though one could do it with a newer "version" of funopen() via symver if the API change was considered ok for 11.0 or 12.0.

Right. The function pointers in sFILE today can only handle the int types. In practice I think 32-bit buffer sizes are probably fine (I don't think it's the performance bottleneck of the read(2)/write(2) interface).

I guess new function pointers or a flag or something could be added to sFILE to distinguish int-funopen-compat sFILEs from size_t-funopen sFILEs? Out of scope for this change, anyway.

[jhb]

Yes, out of scope. I was thinking you would change sFILE to always use size_t and add thunk wrappers for the compat version of funopen() that called the older API callbacks (similar to what you did here)

[oshogbo]

Looks good for me.