Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Date: Fri, 15 Jul 2005 10:12:26 -0400
From: Christopher Faylor <cgf-no-personal-reply-please AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: bug in freopen
Message-ID: <20050715141226.GA13238@trixie.casa.cgf.cx>
Reply-To: cygwin AT cygwin DOT com
References: <071420052313 DOT 28844 DOT 42D6F19F0007DD6E000070AC22007340760A050E040D0C079D0A AT comcast DOT net> <20050714233230 DOT GE26336 AT trixie DOT casa DOT cgf DOT cx> <42D73254 DOT 70109 AT byu DOT net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <42D73254.70109@byu.net>
User-Agent: Mutt/1.5.8i

On Thu, Jul 14, 2005 at 09:49:40PM -0600, Eric Blake wrote:
>According to Christopher Faylor on 7/14/2005 5:32 PM:
>>>#include <stdio.h>
>>>#include <errno.h>
>>>int main(void)
>>>{
>>>  FILE* f = freopen (NULL, "rb", stdin); /* Ensure that stdin is binary */
>>>  printf ("file is %s, errno %d:%s\n", f ? "good" : "null", errno,
>>>          strerror(errno));
>>>  return 0;
>>>}
>>>
>> 
>> Hmm.  It should be pretty simple to just make this always fail with
>> EBADF.  That seems to be a valid thing to do as far as SUSv3 is
>> concerned.
>
>Just because SUSv3 permits EBADF doesn't make it a very good QofI choice.
> I don't think it would be too hard to add code that at least gives an
>attempt to do the right thing using setmode()/fcntl(F_SETFL).

My point here is that I find it rather impertinent to break the behavior
on a platform (cygwin) with the apparent assumption that "someone" is
going to do the work to unbreak it.  So, we could very easily make cygwin
compliant with SUSv3 and that would throw the ball back into the coreutils
court.

OTOH, if you don't think it would be hard to do then why don't *you*
provide a patch?

>> 
>> I am curious, though, as to the rationale behind this change.  I just
>> tried this with -mno-cygwin and it dies with a ENOENT.  So, they
>> apparently removed windows-specific code and replaced it with code
>> that doesn't work on windows...
>
>The rationale was that the main body of code should be as portable as
>possible by sticking to standards, and that platforms that don't meet the
>standards then use wrappers from gnulib.  If newlib's freopen is not
>patched, then coreutils will probably have to add an autoconf test to
>detect that,

Er, yes.  I understand this.

I'm all for making code portable.  This doesn't make the code portable.
It *breaks* the code and assumes that freopen will do the right thing
even though it doesn't do the right thing on the two platforms which
require the behavior that they are coding for.  And, cygwin's behavior
is not that far from being compliant.  This is not portable.

What you are describing is making the code "cleaner" not making it more
portable.

If they wanted to make the code "portable", they should have implemented
the gnulib wrapper along with the cleanup.  Just nuking the existing
code and using an interface which isn't even documented to work on
linux, AFAICT, seems odd to me.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/