Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.