From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx07-00178001.pphosted.com (mx07-00178001.pphosted.com [185.132.182.106]) by sourceware.org (Postfix) with ESMTPS id 7DD5F3858C5F for ; Thu, 5 Oct 2023 18:20:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 7DD5F3858C5F Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=foss.st.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=foss.st.com Received: from pps.filterd (m0369458.ppops.net [127.0.0.1]) by mx07-00178001.pphosted.com (8.17.1.22/8.17.1.22) with ESMTP id 395FsjQe023050; Thu, 5 Oct 2023 20:20:05 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=foss.st.com; h= message-id:date:mime-version:subject:to:references:from :in-reply-to:content-type:content-transfer-encoding; s= selector1; bh=CtESHPs8yO6N6CdSd3IedsUKV/XBHoVFS8A9+SpSh3Y=; b=T0 rc8Fy9pdHWrgzAPr1cbAecZcFOD5PvyGh/L09XVe5+S+xGbxp9rqhA+kDykaKtFW 8pyzeWNtqpCkAow+KbQ4oHw2GgJ7AHAlhm26yAxbSHYKx4tOamQhg4kIgh3VPAZM V6c0zqzQrb+R2Jy1K0E8Tb3m7DifS9JP3W6nWw8XEoR0ZAWhCCNV574k1oplMAG1 oqOsSuf1jzoMs8Gp93odO1dJ+b8RZzcsaB2itZFxPBcEgr26d9M8dgVSYX4AVOEh cbDeI+N10y66SZj6asmg/LFYtzfVbSa/bFR0GqbP2or51SKRsvgmpntRN0M1+mKm WjDAmXOyil2nK+/w5sBA== Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by mx07-00178001.pphosted.com (PPS) with ESMTPS id 3tj06tgdjk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 05 Oct 2023 20:20:05 +0200 (MEST) Received: from euls16034.sgp.st.com (euls16034.sgp.st.com [10.75.44.20]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id A3DA110005C; Thu, 5 Oct 2023 20:20:03 +0200 (CEST) Received: from Webmail-eu.st.com (shfdag1node3.st.com [10.75.129.71]) by euls16034.sgp.st.com (STMicroelectronics) with ESMTP id 5496F28BE9E; Thu, 5 Oct 2023 20:20:03 +0200 (CEST) Received: from [10.252.27.71] (10.252.27.71) by SHFDAG1NODE3.st.com (10.75.129.71) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.27; Thu, 5 Oct 2023 20:20:02 +0200 Message-ID: Date: Thu, 5 Oct 2023 20:20:01 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: fprintf() crashes on wide-oriented stream. Content-Language: en-US To: Takashi Yano , References: <20230926124147.a4dd18b495c6e0347a64fec0@nifty.ne.jp> <20230928125827.b63798bf217baf45c6a5dd22@nifty.ne.jp> <20231005191814.d592433714d3f53cc5827c71@nifty.ne.jp> <20231006001859.5807f14084329e49ed8ae009@nifty.ne.jp> From: Torbjorn SVENSSON In-Reply-To: <20231006001859.5807f14084329e49ed8ae009@nifty.ne.jp> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.252.27.71] X-ClientProxiedBy: SHFCAS1NODE2.st.com (10.75.129.73) To SHFDAG1NODE3.st.com (10.75.129.71) X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.267,Aquarius:18.0.980,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2023-10-05_13,2023-10-05_01,2023-05-22_02 X-Spam-Status: No, score=-5.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,SPF_HELO_NONE,SPF_PASS,TXREP,URIBL_BLOCKED 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: On 2023-10-05 17:18, Takashi Yano wrote: > On Thu, 5 Oct 2023 19:18:14 +0900 > Takashi Yano wrote: >> Hi Jeff, >> >> Thanks for reviewing and the comment. >> >> On Wed, 4 Oct 2023 16:16:13 -0400 >> Jeff Johnston wrote: >>> I finally took a look at this. The issue is whether POSIX compliance is >>> desired. >> >> IIUC, POSIX states that width setting is once decided, it cannot be >> changed until the stream is closed. However, nothing is stated what >> should happen when different width data is output into the stream. >> >>> Corinna would have >>> strong opinions that it is desired and thus, I think she should have her >>> say when she gets back. I personally believe that >>> newlib should have behaved like glibc. I also think the test snippet is >>> invalid and should have performed an fwide call on stdout >>> to reset the wide-orientation and have the code work properly in all cases. >> >> Currently, fputs and fputc works even for wide-oriended stream, so to >> be consistent with that, fprintf also might be better to work. >> >> I wouldn't necessarily expect fprintf to work on wide-oriented streams, >> but buffer overruns should not happen anyway. >> >> So, newlib should be fixed either way. > > As a test, I made a patch attached to make it behave like glibc. > What do you think? Can you please define symbols for those 1 and -1 so that the code would be easier to understand when reading it?