X-Recipient: archive-cygwin AT delorie DOT com DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:reply-to:subject:to:references:from:message-id :date:mime-version:in-reply-to:content-type :content-transfer-encoding; q=dns; s=default; b=r1CkkLSyWb0dWeLH dQC2ofpI7JUoK9/C4wYJ9CEku7k800cI4elFrzQwZE4TuFcqeRcF4Kq+Rk0gzK1T orwKHOWxjYIKI6qkqijr4iHJ4M7npSXoPJBR2lpnSJkh7m206q6GW+agCQaVbfer R0MhW/7131uCG5EXir5BXWw3/rc= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:reply-to:subject:to:references:from:message-id :date:mime-version:in-reply-to:content-type :content-transfer-encoding; s=default; bh=USrNUJ6lZKH68n6emgXygY oDjkI=; b=fsEOS6WATIAbE4qFRRLVqZt5FVDwwFxtCrlGhfu77rwBPqgAL6UTV6 1ht3xuMcWQW0rlEq4J5lOOgG8XF/+7J3Gfu9dvivfu4WsuBoYmOCR4xZin35O7Bu NVyb1JCRzYAeagdnI+NGZ781hMhXklGns6bOaXD0oVZ6vQiBFcXMg= Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 spammy=Alberta, alberta, calgary, Calgary X-HELO: smtp-out-so.shaw.ca X-Authority-Analysis: v=2.2 cv=UpATD64B c=1 sm=1 tr=0 a=MVEHjbUiAHxQW0jfcDq5EA==:117 a=MVEHjbUiAHxQW0jfcDq5EA==:17 a=IkcTkHD0fZMA:10 a=dTgijWl_AAAA:8 a=uPZiAMpXAAAA:8 a=yMhMjlubAAAA:8 a=UEHHlDIcs1zzjgEQaDYA:9 a=ha0ZMB4oAFmqRBeH:21 a=NrQLidBEjOSpSTll:21 a=QEXdDO2ut3YA:10 Reply-To: Brian DOT Inglis AT SystematicSw DOT ab DOT ca Subject: Re: CR-LF handling behavior of SED changed recently - this breaks a lot of MinGW cross build scripts To: cygwin AT cygwin DOT com References: <0F7D3B1B3C4B894D824F5B822E3E5A175B2636E4 AT IRSMSX103 DOT ger DOT corp DOT intel DOT com> <0F7D3B1B3C4B894D824F5B822E3E5A175B26CE47 AT IRSMSX102 DOT ger DOT corp DOT intel DOT com> <59399CC5 DOT 60900 AT tlinx DOT org> <417f84ac-5d9f-dc50-e912-973e90b8a128 AT redhat DOT com> <0F7D3B1B3C4B894D824F5B822E3E5A175B26F278 AT IRSMSX102 DOT ger DOT corp DOT intel DOT com> <34b26965-34c2-b5f0-a3f2-b2c3df344b08 AT gmail DOT com> <0F7D3B1B3C4B894D824F5B822E3E5A175B270518 AT IRSMSX102 DOT ger DOT corp DOT intel DOT com> <5313de97-d9bd-d9c9-cb4a-254a3eadcf4a AT redhat DOT com> <3100fec0-bed0-f2fd-fe3c-11e5580d80f0 AT redhat DOT com>

<9d085703-04a5-3191-fd6b-7b06f407b47b AT gmail DOT com> From: Brian Inglis Message-ID: <27132e6d-7fc6-41e0-1d30-88d708ddc061@SystematicSw.ab.ca> Date: Wed, 14 Jun 2017 13:04:20 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <9d085703-04a5-3191-fd6b-7b06f407b47b@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfPAm1QXYAqXCWrYageojtkieW/4x0Ru+lypJ5bzsVJapcOVLawMYOKMo+dEWUHVTv+lVVzeVX9QqYIPC6+DAicnqyM4aru5hGRFKXng7OO+/4e/zwZaD Io5wx4/0rSOZQxwcPXR5IaxSEsTzqwsUT0PY8sEosgtbVHw7cUlHeTcbto3Ax9MsZrN3fqpp0QNo2A== X-IsSubscribed: yes On 2017-06-14 10:07, cyg Simple wrote: > On 6/13/2017 1:34 PM, Brian Inglis wrote: >> On 2017-06-13 08:11, cyg Simple wrote: >>> On 6/10/2017 10:30 PM, Eric Blake wrote: >>>> On 06/10/2017 08:48 AM, cyg Simple wrote: >>>>> Uhm, 'wt' and 'wb' came from MS itself. >>>> Not quite. fopen(,"wb") comes from POSIX. "wt" is probably a microsoft >>>> extension, but it is certainly not in POSIX nor in glibc. >>> I think it's a C standard so it should be in glibc. It may be mentioned >>> in the POSIX standard as in support of the C standard. >>>>> GNU GCC was adapted to allow it >>>> Huh? It's not whether the compiler allows it, but whether libc allows >>>> it. ALL libc that are remotely close to POSIX compliant support >>>> fopen(,"wb"), but only Windows platforms (and NOT glibc) support >>>> fopen(,"wt"). >>> Looking at http://www.cplusplus.com/reference/cstdio/fopen/ I see: >>> "If additional characters follow the sequence, the behavior depends on >>> the library implementation: some implementations may ignore additional >>> characters so that for example an additional "t" (sometimes used to >>> explicitly state a text file) is accepted." >>> There is also a lot of discussion about the topic at: >>> https://stackoverflow.com/questions/229924/difference-between-files-writen-in-binary-and-text-mode >>> As for glibc, it will just ignore the extra character but it allows the >>> use of "wt"; it just means nothing to that C runtime library. It does >>> aide in portable code though. >>> As for me conflating GCC with a C runtime - please forgive my lapse in >>> memory. >> >> There's no need for open mode "t", as text is the default mode unless >> "b" is specified, and assuming you use "cooked" line I/O functions like >> fgets/fputs, not "raw" binary I/O like fread/fwrite; fscanf ignores all >> line terminators unless you use formats like "%c" which could see them. >> > > That isn't exactly true based on the MSDN[1] the "t" manages the CTRL-Z > EOF marker. However, I agree that it worthless. But regardless the C > standard states that "t" or whatever extra character can be added and > left to the implementing library to interpret or ignored. If the C > runtime library doesn't use it or ignore it then it isn't complying to > the C standard. The Standard supports only /[ra](b|+|b+|+b)?|w(b|+|b+|+b)?x?/, although implementations may choose to ignore some of the allowed trailing characters (presumably "b", "+", or "x", as the footnote is unclear), or the file so created may not be accessible as a stream, and anything else invokes UB. "7.21.5.3 The fopen function Synopsis 1 #include FILE *fopen(const char * restrict filename, const char * restrict mode); Description ... 3 The argument mode points to a string. If the string is one of the following, the file is open in the indicated mode. Otherwise, the behavior is undefined.[271] r open text file for reading w truncate to zero length or create text file for writing wx create text file for writing a append; open or create text file for writing at end-of-file rb open binary file for reading wb truncate to zero length or create binary file for writing wbx create binary file for writing ab append; open or create binary file for writing at end-of-file r+ open text file for update (reading and writing) w+ truncate to zero length or create text file for update w+x create text file for update a+ append; open or create text file for update, writing at end-of-file r+b or rb+ open binary file for update (reading and writing) w+b or wb+ truncate to zero length or create binary file for update w+bx or wb+x create binary file for update a+b or ab+ append; open or create binary file for update, writing at end-of-file ... [271] If the string begins with one of the above sequences, the implementation might choose to ignore the remaining characters, or it might use them to select different kinds of a file (some of which might not conform to the properties in 7.21.2." > [1] https://msdn.microsoft.com/en-us/library/yeby3zcb(v=vs.140).aspx > > "t > Open in text (translated) mode. In this mode, CTRL+Z is interpreted as > an EOF character on input. In files that are opened for reading/writing > by using "a+", fopen checks for a CTRL+Z at the end of the file and > removes it, if it is possible. This is done because using fseek and > ftell to move within a file that ends with CTRL+Z may cause fseek to > behave incorrectly near the end of the file." Wonder if "t" is also required in order to have recognized as console input EOF? That page also documents a bunch of other mode characters and encoding arguments that make that implementation far from Standard. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple