[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
