From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dmta0017.nifty.com (mta-snd00003.nifty.com [IPv6:2001:268:fa04:731:6a:99:e2:23]) by sourceware.org (Postfix) with ESMTPS id D434D3858C5E for ; Wed, 8 Nov 2023 12:05:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D434D3858C5E 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 ARC-Filter: OpenARC Filter v1.0.0 sourceware.org D434D3858C5E Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2001:268:fa04:731:6a:99:e2:23 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1699445122; cv=none; b=bQBv3pdJqPUsLnWfWWQhk04Q1woqzLnet0d96RJt7pN4OPyaRRvQslf1jSHvYEZcKPTQCOi0sV5Y87cXMi9KddHDYbZVOPZYterUICtFK0JLFVkYF6XMJPrw1l2vCy8KWQEcV+YhyPNFoCzq1xAHf4lKbIdeuggad1ippBgtraM= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1699445122; c=relaxed/simple; bh=je/wHB4BHPNLeQ8LqBQVdUPKLE5zi6sKa2XUtEw2Vm4=; h=Date:From:To:Subject:Message-Id:Mime-Version; b=jlAhOK6F3duJm5wVVsVLpgrkKbWe8PLKRBjsHgwwac0j6PvUPkkfHs5r5uRx/HInbVWyOY27gqCmvavQLg2nsTvD4sF9TiFpXfata7LlIBpWnflksyvD8nF8XAPJawF85GKNH7iIYbSn1x45oLeoAnU0DI9buePJfz3+dA+p2VU= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from HP-Z230 by dmta0017.nifty.com with ESMTP id <20231108120515463.LWLK.61751.HP-Z230@nifty.com> for ; Wed, 8 Nov 2023 21:05:15 +0900 Date: Wed, 8 Nov 2023 21:05:16 +0900 From: Takashi Yano To: newlib@sourceware.org Subject: Re: fprintf() crashes on wide-oriented stream. Message-Id: <20231108210516.6493ec17b652b3149ebf770a@nifty.ne.jp> In-Reply-To: References: <20230926124147.a4dd18b495c6e0347a64fec0@nifty.ne.jp> <20230928125827.b63798bf217baf45c6a5dd22@nifty.ne.jp> <20231005191814.d592433714d3f53cc5827c71@nifty.ne.jp> <20231006001859.5807f14084329e49ed8ae009@nifty.ne.jp> 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=-5.1 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,NICE_REPLY_A,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: Hi Corinna, On Tue, 7 Nov 2023 14:24:47 +0100 Corinna Vinschen wrote: > Hi Takashi, hi Jeff, > > > I checked the history of the orientation stuff and I think I came to a > conclusion. > > On Oct 6 00: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 > > You can't reset the orientation once it's set. fwide(3) only allows > to change the orientation if it's still undecided. Once you did > set the orientation, you can't change it back, neither to undecided, > nor to the other orientation. freopen(3) is the only way to reset > the orientation to undecided. > > > 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? > > It took me a while, but I think the BSD behaviour is only accepted > (acceptable) due its long history. The only really correct way of > handling this issue is to do soemthing along the lines of GLibC. > > I. e., while "cannot be applied" is sufficently vague, it should be > interpreted as "must not be applied", basically. However, "must not" > kind of implies setting errno, but there's not a trace of that in > the standard. > > Consequentially, IMHO, the way GLibC handles it sounds like the best way > out: The call is a no-op and returns a value indicating that the stream > isn't available for the given operation (EOF/WEOF/younameit), but it > does not change errno. There's no errno value defined for this kind > of problem anyway. > > Takashi, assuming everybody is ok, your patch below looks good. I'm > just wondering if we really need an extra QUERY_ORIENT() macro. What if > ORIENT() itself returns the actual value? That would allow to just > write, for instance > > - ORIENT(fp, 1); > + if (ORIENT(fp, 1) != 1) > + return WEOF; Thanks for reviewing the patch. I revised the patch as you suggested. Please see v4 patch I have just posted. -- Takashi Yano