[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <51436EB0.8030007@eservices.virginia.edu>
Date: Fri, 15 Mar 2013 14:55:44 -0400
From: Zvi Gilboa <zg7s@...rvices.virginia.edu>
To: <musl@...ts.openwall.com>
Subject: Re: question: hard-coded file descriptors in stdin/stdout/stderr
Thank you for the encouragement, Rich! It is great to know that the
project will be warmly welcome by the musl community. As for the
incremental "case-by-case basis" translation of error codes, as well as
handling of corner cases: my method thus far has been to create raw text
files with the basic mapping information, and then generate the header
and source files using command-line tools such as awk, gawk, sed, etc
(which forces me to actually understand what I need to achieve...) This
means that covering more cases in the future by me or other developers
should be a rather self-contained task, requiring only minimal knowledge
about the library as a whole.
>> "hacks all over the core to deal with the badness of msvcrt"
No way I could express this better:)
Zvi
On 03/15/2013 02:43 PM, Rich Felker wrote:
> 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.
