|
Message-ID: <51420E17.9030305@eservices.virginia.edu> Date: Thu, 14 Mar 2013 13:51:19 -0400 From: Zvi Gilboa <zg7s@...rvices.virginia.edu> To: <musl@...ts.openwall.com> Subject: Re: question: hard-coded file descriptors in stdin/stdout/stderr >> 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:) 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. * 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. Best regards, Zvi On 03/14/2013 01:17 PM, Szabolcs Nagy wrote: > * Zvi Gilboa <zg7s@...rvices.virginia.edu> [2013-03-14 12:18:53 -0400]: >> I just noticed that the file descriptors in stdin.c, stdout.c, and >> stderr.c do not use the #defines from <unistd.h> (namely >> STDIN_FILENO, STDOUT_FILENO, and STDERR_FILENO), but are rather >> hard-coded (as 0, 1, and 2 respectively). I was therefore wondering > these numbers are fixed on posix (and linux and all historical unices) > > the macro definitions are there for conformance reasons > > it's like using 0 instead of NULL or -1U instead of UINT_MAX > > >> this would normally not be an issue, however there are still some >> systems out there with standard file descriptor numbers which are >> different... > which ones? > >> On that same note: wouldn't it make sense to slightly modify >> unistd.h so that it first checks whether STDIN_FILENO, etc. have > i dont think it makes sense for a linux libc > to have these numbers configurable
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.