To: cygwin@cygwin.com
From: mwoehlke <mwoehlke@tibco.com>
Subject:  Re: cygwin fork()
Date:  Fri, 01 Sep 2006 17:30:34 -0500
Lines: 25
Message-ID: <edacaa$hq0$1@sea.gmane.org>
References:  <002c01c6ce13$1094de50$020aa8c0@DFW5RB41> <44F8B0F7.EA3A0706@dessent.net>
Mime-Version:  1.0
Content-Type:  text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding:  7bit
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.5) Gecko/20060719 Thunderbird/1.5.0.5 Mnenhy/0.7.4.0
In-Reply-To: <44F8B0F7.EA3A0706@dessent.net>
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Precedence: bulk
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com

Brian Dessent wrote:
> "Gary R. Van Sickle" wrote:
>>> AFAIK, Cygwin's lseek should handle seeking on text streams.
>>> DJ implemented that years ago.
>> Last I looked, which was admittedly also years ago, it was "#if 0"'ed out,
>> with a comment to the effect of "Nobody has any business seeking around in
>> text files."
> 
> FWIW, mingw's lseek() (which is actually Microsoft's, since mingw
> targets MSVCRT.DLL) is horribly broken when seeking on a file opened in
> text mode.  But it's documented as such on MSDN, so at least there's
> that.  So there is some precedence for the concept that "this won't work
> on windows platforms."
> 
> But Cygwin's should work fine, and if it means saving a bazillion 1-byte
> syscalls then I think bash should be patched to remove this sillyness
> ASAP.

I'll *emphatically* second the 'doing something about it'; I'm also 
cursed by really slow builds. (Assuming I understand what is going on, 
anyway :-))

-- 
Matthew
Do not expose to hippos. Doing so may void your warranty.


--
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/