From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=fysI=DQ=nifty.ne.jp=takashi.yano@sourceware.org>
Received: from dmta1014.nifty.com (mta-snd01008.nifty.com [106.153.227.40])
	by sourceware.org (Postfix) with ESMTPS id CBFD63858D35
	for <cygwin@cygwin.com>; Sun, 30 Jul 2023 11:37:38 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org CBFD63858D35
Authentication-Results: sourceware.org; dmarc=fail (p=none dis=none) header.from=nifty.ne.jp
Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=nifty.ne.jp
Received: from HP-Z230 by dmta1014.nifty.com with ESMTP
          id <20230730113736237.WXG.25686.HP-Z230@nifty.com>;
          Sun, 30 Jul 2023 20:37:36 +0900
Date: Sun, 30 Jul 2023 20:37:35 +0900
From: Takashi Yano <takashi.yano@nifty.ne.jp>
To: cygwin@cygwin.com
Cc: moss@cs.umass.edu
Subject: Re: Probable bug
Message-Id: <20230730203735.7d94749b4f08a9de9cc3ca9f@nifty.ne.jp>
In-Reply-To: <bf5f14f8-8dfd-13da-87b5-a0117fd04b05@cs.umass.edu>
References: <199362107.5561484.1690709920649@mail1.libero.it>
	<bf5f14f8-8dfd-13da-87b5-a0117fd04b05@cs.umass.edu>
X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.30; i686-pc-mingw32)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, score=-3.5 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org
List-Id: <cygwin.cygwin.com>

On Sun, 30 Jul 2023 07:29:10 -0400
Eliot Moss wrote:
> On 7/30/2023 5:38 AM, natan_b--- via Cygwin wrote:
> > Hi Guys
> > 
> > very short.
> > 
> > prog.c
> > 
> > #include <stdio.h>
> >   
> > int main()
> > {
> > float a=1.283;
> > while(1)
> > printf( "%f", a );
> > }
> >   
> > run with
> > $ ./prog.exe >/dev/null
> >   
> > in windows monitor process the process increase it's memory it arrive to many  Gb.
> > It's not a machine problem, other PC have same problem.
> >   
> > Same program in wsl and MSYS2 works well!
> 
> This probably has to do with output buffering, and may happen even without
> the >/dev/null since there are no line ends in the output.  It may work with
> stdbuf -o0 (as in: stdbuf -o0 ./prog.exe >/dev/null) but may cause the program
> to run more slowly (each character is sent to the device, when then immediately
> discards it).  It would seem you're hoping for the internal libraries to
> recognize the case of writing to /dev/null ...

I also suspected that, however, it was not correct.

while (1) sprintf(buf, "%f\n", a);

has the same problem. :-(

-- 
Takashi Yano <takashi.yano@nifty.ne.jp>