Re: question: hard-coded file descriptors in stdin/stdout/stderr

[Zvi Gilboa <zg7s@eservices.virginia.edu>]

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