[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 17 Mar 2013 23:26:31 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: question: hard-coded file descriptors in
stdin/stdout/stderr
On Sun, Mar 17, 2013 at 10:14:00PM -0500, Rob Landley wrote:
> On 03/14/2013 12:51:19 PM, 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:)
>
> All possible reasons? I can't think of one.
>
> I have actually thought about this sort of thing. For example, I did
> a talk at the recent emebedded Linux conference explaining _why_
> toybox and musl are important to Android:
>
> http://www.youtube.com/watch?v=SGmtP5Lg_t0
>
> >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).
>
> In DOS, stdin, stdout, and stderr were 0, 1, and 2. What you just
> listed is an explicit violation of posix.
This issue was already resolved. There's no need to flame...
> > 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.
>
> You want to introduce non-posix assumptions into musl to make
> windows code more elegant.
>
> Really?
No, he just wanted to eliminate some assumptions (guaranteed by POSIX)
and use macros instead of hard-coded magic numbers. But this turned
out not to be necessary or useful anyway, for reasons connected to the
ones you cited. We arrived at this conclusion with no need for
flaming. :-)
> >* 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.
>
> Doesn't mingw already exist?
mingw is not a libc. It uses msvcrt, which is horrible. The reason for
getting a real proper libc on windows is not to make windows' users
lives easier, or at least that's not my reason for wanting it. Rather,
it makes OUR lives easier, because FOSS projects can just target POSIX
and keep their cores simple, rather than being full of #ifdef hell or
"portable runtime" hell.
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.
