[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130315083357.GH20323@brightrain.aerifal.cx>
Date: Fri, 15 Mar 2013 04:33:57 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: question: hard-coded file descriptors in
stdin/stdout/stderr
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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
