This shim could have been convenient for applications. If not named "internal", we could export the header file and allow apps including it. Otherwise the app can recreate this file on its side, it is not a big deal. Opinions?
Based on my experience with SPDK, I believe this would get messy very quickly. For example, a common usage is to redefine close to _close. If the application is going to use sockets without requiring changes, then a fake fd is needed to represent a socket and close has to handle it as well ... which will clash with the 'simplistic' redefinition to _close, so we'd need some way of turning these on/off individually. I think there are really only two models that are viable - either an external POSIX layer that is used by everything (in the general case, Cygwin would be an example), or a private implementation that is not exposed publicly. Keeping the implementation private is not just about keeping POSIX out of the headers. It's about avoiding conflicts with the application; e.g. making sure that any signal implementation can co-exist with the application. Regards, Nick
