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:to:subject:mime-version:content-type :content-transfer-encoding:date:from:in-reply-to:references :message-id; q=dns; s=default; b=RUWs7TLdOeH1FD/k1Dlkf+Isnmdae1m Fhs7kK/DuZcWmSOTeQeVmb1bLB8FPgNapTfiOMJzyLeStOrt51/R04qt35igWdNG E3SxTpes9sDO+MyRDAOMK9gqYlw4PT/8YtjZIf/sWsfbNmn0eOLSx2yoQU9u2Ego 9UHCG7vyIPL8= 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:to:subject:mime-version:content-type :content-transfer-encoding:date:from:in-reply-to:references :message-id; s=default; bh=H0ztlxH5/j8e+OvnJSgcEMEXId4=; b=lkQ4D 8PWOaxvJxTd9Vi46InyMwLPKAKdA4V6hjQjB2C7jUnlE00+AFZN3MzukQ7n41sZ1 5/9VriJ/vquPwGq4ZRDY5GxePxTmyHNOAMUl7+37/ho9cbK7f/lQTiVeAexOVUnJ S49gOUCfQbj78lXqZZ/rqlwP7vWqYPY6GHGtik= 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.0 required=5.0 tests=AWL,BAYES_00,FROM_STARTS_WITH_NUMS,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=compliance, fclose, fseek, fopen X-HELO: smtp-out-so.shaw.ca X-Authority-Analysis: v=2.1 cv=Daa30qZW c=1 sm=1 tr=0 a=WiYoHcCliNeVponEdG0Ckg==:117 a=WiYoHcCliNeVponEdG0Ckg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=SMorJkV_YP8A:10 a=7OsogOcEt9IA:10 a=jKhqh5cNbzYDnnjIO9EA:9 a=QEXdDO2ut3YA:10 To: cygwin AT cygwin DOT com Subject: Re: Problem with line buffering and getc function on 1.7.33. X-PHP-Originating-Script: 501:rcmail.php MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Date: Fri, 11 Mar 2016 16:05:02 -0800 From: Kaz Kylheku <920-082-4242 AT kylheku DOT com> In-Reply-To: <56E34346.9010000@gmail.com> References: <56E34346 DOT 9010000 AT gmail DOT com> Message-ID: <11ca145175d5b7d15db927c0c1f28b18@mail.kylheku.com> X-Sender: 920-082-4242 AT kylheku DOT com User-Agent: Roundcube Webmail/0.9.2 X-CMAE-Envelope: MS4wfLTm9tSkuD4EQqpLRyn+or7YJoWuN9t09bRFeBBdRZhb0Tp6GnirBtGvvq2IL5hOQHVBhGFZ/4O+3RXvqwJ+ulJxWPkojEStlJWzMe0CT2rlGN+ZjJ3Y EjFNhVvo/hpCINr3DXd3vgs01c9O2vOgHqzVlZDMyjPrZ3m6k4Vm8pqC X-IsSubscribed: yes Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id u2C05K35030280 On 11.03.2016 14:14, Marco Atzeri wrote: > On 11/03/2016 22:57, Kaz Kylheku wrote: >> On 11.03.2016 12:08, Yaakov Selkowitz wrote: >>> On 2016-03-11 13:16, Kaz Kylheku wrote: >>> >>>> On a Cygwin installation version 1.7.33-2(0.280/5/3), I encountered >>>> an odd issue. >>> >>> This is a 15-month old release which is no longer supported. Please >>> update to 2.4.1. >> >> Do you mean, "Please update to 2.4.1, it is fixed there!" >> or do you mean "You haven't done enough with that minimal >> C repro case; please keep investigating against >> the latest code?" > > #2 please verify if the issue is still present in the last code. > We don't have the bandwith to check claims on older release. > on 2.4.1 the output is: > > $ ./test_stream.exe > received REQUEST > from client > received > from server That confirms that the issue is still there. We can reproduce the problem with just file streams using a much simpler program: #include int main(void) { FILE *out = fopen("file", "w+"); setvbuf(out, (char *) NULL, _IOLBF, 0); getc(out); clearerr(out); fseek(out, 0, SEEK_SET); putc('a', out); putc('b', out); putc('c', out); putc('d', out); putc('e', out); putc('\n', out); fclose(out); return 0; } The contents of file end up being "\n": one empty line, instead of "abcde\n": $ cat file $ The necessary ingredients seem to be: open the stream for update; put into line buffered mode; do some input. In this program, replacing putc with fputs doesn't make the problem go away; the workaround isn't working: fputs("a", out); fputs("b", out); fputs("c", out); fputs("d", out); fputs("e", out); fputs("\n", out); However, if we do it as one string, then the file does contain the correct line: fputs("abcde\n", out); This sequence also gets us correct file contents: fputs("ab", out); putc('c', out); putc('d', out); putc('e', out); putc('\n', out); HOWEVER, these distracting effects are because GCC is optimizing one-character fputs calls into _fputc calls. Annoyingly, this happens even with gcc -O0. The clearerr and fseek calls are red herrings; they seem to make make no difference. I put in the fseek for formal ISO C compliance: ISO C says that before performing an output operation on an update stream whose last operation was input, we "shall" perform a positioning operation. (No sanely implemented libc actually breaks code that doesn't meet this silly requirement.) -- 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