X-Recipient: archive-cygwin AT delorie DOT com DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D908D385841C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com; s=default; t=1690717076; bh=0UkECV/xHs4VC/MDCvlJRaheaeiFbnqMzg4xMv5xAmA=; h=Date:To:Cc:Subject:In-Reply-To:References:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=CtiooWwzny0mQ8oC7KWit+M1/t6C8JkmzgVVGiSQaPQe2YUzfDULNHv4FOLhp+sk5 l2JY7f3q7c5KoaXysfItlBYZhBaPe6NQ0NaqMP0WFnjgA1AWEYBJu1IyO8y7RMvjHU JGSvnfKmYMUcDL9BkFXsSZ4lEkzsfCTAit9/bPZw= X-Original-To: cygwin AT cygwin DOT com Delivered-To: cygwin AT cygwin DOT com DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org CBFD63858D35 Date: Sun, 30 Jul 2023 20:37:35 +0900 To: cygwin AT cygwin DOT com Cc: moss AT cs DOT umass DOT edu Subject: Re: Probable bug Message-Id: <20230730203735.7d94749b4f08a9de9cc3ca9f@nifty.ne.jp> In-Reply-To: References: <199362107 DOT 5561484 DOT 1690709920649 AT mail1 DOT libero DOT it> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.30; i686-pc-mingw32) Mime-Version: 1.0 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 X-BeenThere: cygwin AT cygwin DOT com X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Cygwin discussions and problem reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Takashi Yano via Cygwin Reply-To: Takashi Yano Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: cygwin-bounces+archive-cygwin=delorie DOT com AT cygwin DOT com Sender: "Cygwin" 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 > > > > 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 -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation: https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple