Re: question: hard-coded file descriptors in stdin/stdout/stderr

[Rich Felker <dalias@aerifal.cx>]

On Thu, Mar 14, 2013 at 01:51:19PM -0400, Zvi Gilboa wrote:
> >> which ones?
> 
> .... since you are asking...  inspired by musl-libc, I am currently
> writing a win32/win64 open-source library that implements/provides
> POSIX system calls (see note below).  I believe that having a
> powerful libc with an MIT license available on Windows would
> actually be of great value to the open source community for all
> possible reasons, but that is of course irrelevant to my question:)

This is actually something I've wanted to see done for a long time, so
I wish you the greatest success on your project. Despite my general
aversion to using the STDIN_FILENO etc. macros, if your project takes
off and this issue is a major obstacle to pulling up-to-date code from
musl, I would probably consider just using them. But...

> The main issue here is that the standard file descriptors on Windows
> are -10 (STD_INPUT_HANDLE), -11 (STD_OUTPUT_HANDLE), and -12
> (STD_ERROR_HANDLE).  I could of course compensate for that in my
> code and "translate" the POSIX special file descriptor numbers to
> the Windows ones, however it would be more elegant if musl-libc used
> the descriptors defined in <unistd.h>  instead of hard-coded
> numbers.

When I originally proposed an idea similar to what you're doing, one
of the open-ended questions was "how much" of POSIX such a libc (for
Windows) should aim for. Since we weren't actually doing the project,
a lot of questions were left unanswered, but I think this sort of file
descriptor remapping is something you really should do. Not only are
the numbers 0/1/2 specified and widely hard-coded in applications; the
Windows "file handle" values for stdin/out/err are not usable as file
descriptors because they are negative. They definitely aren't
compatible with select(), and probably have a lot of other issues
where they clash with the interpretation of a negative return value as
an error (e.g. dup2(fd,-10) would return -10, which applications would
interpret as an error). If you want to make sockets and regular file
file descriptors a common space (which is needed for close() to work,
as well as select()/poll()) I think that also requires a remapping of
windows file/socket handles to POSIX-style file descriptor numbers.

> * as for psxcalls: this is a C library, that exclusively uses the
> Native API.  It attaches to ntdll.dll during run-time, and can thus
> be compiled as a "native" static library with no external
> dependencies.  While it is currently in its very initial stage (and
> not yet online), the major "obstacle" features -- including fork()
> -- have already been implemented.  To remove all doubts, I am aware
> of Cygwin's existence, yet am looking for a high-performance
> solution that would be both "clean"
> (psxcalls-->libc-->user-library-or-application), and flexibly
> licensed.

Nice to hear. Incidentally, fork() was one of the interfaces I thought
we could just sacrifice in doing such a libc (posix_spawn or the
similar Windows function can replace most correct uses of fork()), so
it's nice to hear you've solved the problem.

Rich