Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130315184300.GI20323@brightrain.aerifal.cx>
Date: Fri, 15 Mar 2013 14:43:00 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: question: hard-coded file descriptors in
 stdin/stdout/stderr

On Fri, Mar 15, 2013 at 10:46:54AM -0400, Zvi Gilboa wrote:
> >> [Rich wrote:] Not only are the numbers 0/1/2 specified and widely
> hard-coded in applications;
> 
> >> [LM wrote:] I've been trying to port msh to Windows and it uses
> hard-coded 0, 1 and 2 with pipes and expects them to mean stdin,
> stdout and stderr.
> 
> Thank you for this valuable input!  Clearly, remapping 0/1/2 from
> within psxcalls would be the only responsible approach:)

Note that even if the shell doesn't hard-code them, every single
non-trivial shell script ever written hard-codes them. I think this
was the motivation for POSIX requiring that they have the specific
values 0/1/2.

> That kind of "translation" is an essential part of the psxcalls
> project.  Surprisingly (or not), the vast majority of differences
> between the Native API and POSIX are about syntax, not
> functionality.  In other words, there exist only very few POSIX
> features that cannot be implemented using the Native API in a
> straight-forward way.  There are for sure some cases that require

That's nice to hear. I suspect there are a lot more subtleties like
different error conditions and corner cases, which probably need
consideration on a case-by-case basis whether it's important to match
the POSIX behavior (or whether it's even possible to match it
exactly). Still, I think most such problems are things that can be
solved incrementally, and shouldn't stall the project.

> programming acrobatics (fork() and exec()) being the most obvious
> examples), but that's the exception, not the rule.  Whenever I
> implement one of the functions, I try to phrase the task in the form
> of a question, for instance: "using the Native API, how would you
> map a memory page to the address space of a user applications?"
> That kind of approach to writing the library surely entails a lot of
> work, but is also very exciting -- like solving a puzzle every
> single day...

Keep up the good spirits -- I'm glad to see this finally happening. My
hope for the past 7+ years has been that we could get to a point where
software (or at least FOSS) could be written with a portable core
targetting POSIX rather than having windows-specific hacks all over
the core to deal with the badness of msvcrt, or bloated "portable
runtime" libraries that layer abstractions on top of the standardized
abstractions.

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.