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

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

 >> My concern isn't that you'll succeed or fail either way, it's that 
in trying to do it you'll mess up the nice clean Linux C library Rich 
has made by forcing a bunch of non-posix assumptions on it.

No need to worry, I shall never do something like that.  As mentioned a 
couple of days ago, my library is written so that all additions to musl 
will take place in the form of architecture-specific sub-folders, as is 
the case today with mips, x86_64, etc.


 >> This assumption that started this thread is a perfect example... so 
musl relying on what posix said _is_ what you were objecting to.

Not really an assumption, just an attempt to better understand things.  
The answers I received were enlightening and very useful, and thus saved 
me a lot of time.  I also do not recall trying to object to the current 
musl implementation, hence the use of question marks and the subjunctive 
mood in my original post:)


 >> I don't understand why this new approach thinks it won't encounter 
the problems of either previous project. I'd wait to see code...

You know, sometimes dreams come true.  Maybe mine will be one of them.

ZG






On 03/18/2013 12:22 AM, Rob Landley wrote:
> On 03/17/2013 10:28:51 PM, Zvi Gilboa wrote:
>> >> Doesn't mingw already exist?
>>
>> Of course it does, but it does not allow one to compile unmodified 
>> posix code.
>>
>>
>> >> How on earth does licensing on WINDOWS matter, since the base OS 
>> is proprietary? So this is explicitly "provide free stuff to make 
>> paying money to Microsoft more appealing"?
>>
>> My approach on that issue is apparently rather different.  But as often
>> happens, the greatest resistance comes not from those who oppose 
>> one's goal,
>> but rather from those who share the same goal, yet differ in their 
>> vision as
>> to how it should be reached.  My hope is that as my project evolves, 
>> you,
>> too, will become one of its supports.
>
> Oh no, I oppose your goal entirely. I think that a posix libc 
> attempting to support windows is a bad idea.
>
> My concern isn't that you'll succeed or fail either way, it's that in 
> trying to do it you'll mess up the nice clean Linux C library Rich has 
> made by forcing a bunch of non-posix assumptions on it. (I.E. fork it 
> all you like, that's merely useless, but pushing this stuff upstream 
> makes no sense to me and seems actively harmful.)
>
> This assumption that started this thread is a perfect example. The 
> posix-2008 stdin definition under system interfaces in the function 
> list explicitly says that stdin is 0, stdout is 1, and stderr is 2. So 
> musl relying on what posix said _is_ what you were objecting to. 
> Meanwhile Rich is saying that letting windows programs rely on posix 
> is the advantage of your approach. This seems like a direct conflict 
> to me.
>
> It is of course Rich's call not mine. But I'm not following the logic 
> at all.
>
> Rob