From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 87B433858D33 for ; Tue, 7 Nov 2023 13:25:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 87B433858D33 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 87B433858D33 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1699363504; cv=none; b=Fzzbm3vpoihQUvHvEOaBiuvn/FJZv1yfAfGv6aXKeQSfurZMWDctscPpAWGiWovUPyRHrMDLF/ndal5fdmDPty/vfFTsruZhGPW69dqX3HVBODUzgndVTSBVFI+8XSACDFZI3wl/TDjGPGgyND/a4vXEekze3XLwYGmFF7zoI/Y= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1699363504; c=relaxed/simple; bh=wcRf3k22JgjOlT2U+zcWon8jAiTtfUs/Eexd42M55g0=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=xBHmo4evtnayN+AnmsgZr+3e88qsAV8o2EdYgnQSempatpvMRTQCGkbdJjGCKdZgaL3TP9o2O8GtCLLOzC2l8dy0au3rmX++NekgvwrJLDwapfvEfO2FOK9793n+6+1+BJ5aLcy8Psc26z41iWJ9JXdCkajCx2micVFNAq64fvQ= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1699363503; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references; bh=PM7pzqqJ4q1Z/VZCgzWPpgXKWuKTbLsYG4Jfzq51ivE=; b=Co9v58B+um2mCTp01SL5JVT2SDZ+Xb/RVnB2sTbrA636U2RJRrKVljVNpkQS+txn+OwU6/ CX4+142II5oOgnwTarx1+xQZUSwD1Eeq0B+US0Ys5mQ9VxzTxW/27fjPBtJU7iecqgsf+/ 4rqSur+JnnJjuKZp1nA3FPYAEnimLCk= Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-619-BfzAnYGhNySQAkWKEO3YIQ-1; Tue, 07 Nov 2023 08:24:49 -0500 X-MC-Unique: BfzAnYGhNySQAkWKEO3YIQ-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.rdu2.redhat.com [10.11.54.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 1462828B72EC; Tue, 7 Nov 2023 13:24:49 +0000 (UTC) Received: from calimero.vinschen.de (unknown [10.39.192.157]) by smtp.corp.redhat.com (Postfix) with ESMTPS id C9FB125C0; Tue, 7 Nov 2023 13:24:48 +0000 (UTC) Received: by calimero.vinschen.de (Postfix, from userid 500) id 399E0A807B8; Tue, 7 Nov 2023 14:24:47 +0100 (CET) Date: Tue, 7 Nov 2023 14:24:47 +0100 From: Corinna Vinschen To: Takashi Yano Cc: newlib@sourceware.org Subject: Re: fprintf() crashes on wide-oriented stream. Message-ID: Reply-To: newlib@sourceware.org Mail-Followup-To: Takashi Yano , newlib@sourceware.org References: <20230926124147.a4dd18b495c6e0347a64fec0@nifty.ne.jp> <20230928125827.b63798bf217baf45c6a5dd22@nifty.ne.jp> <20231005191814.d592433714d3f53cc5827c71@nifty.ne.jp> <20231006001859.5807f14084329e49ed8ae009@nifty.ne.jp> MIME-Version: 1.0 In-Reply-To: <20231006001859.5807f14084329e49ed8ae009@nifty.ne.jp> X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.1 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Spam-Status: No, score=-5.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,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 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, Corinna