New issue from Jan Kokemüller: "§[ostream.formatted.print]: Inappropriate usage of badbit in definition of vprint_unicode/vprint_nonunicode"

Author: Dani-Hub

xml/issue4039.xml

@@ -0,0 +1,75 @@
+<?xml version='1.0' encoding='utf-8' standalone='no'?>
+<!DOCTYPE issue SYSTEM "lwg-issue.dtd">
+
+<issue num="4039" status="New">
+<title>&sect;[ostream.formatted.print]: Inappropriate usage of <tt>badbit</tt> in definition of 
+<tt>vprint_unicode</tt>/<tt>vprint_nonunicode</tt></title>
+<section><sref ref="[ostream.formatted.print]"/></section>
+<submitter>Jan Kokemüller</submitter>
+<date>13 Jan 2024</date>
+<priority>99</priority>
+
+<discussion>
+<p>
+In section <sref ref="[ostream.formatted.print]"/>, bullet 3.2 there is a mention of <tt>badbit</tt>:
+</p>
+<blockquote>
+<p>
+any exception thrown by the call to <tt>vformat</tt> is propagated without regard to the
+value of <tt>os.exceptions()</tt> and without turning on <tt>ios_base::badbit</tt> in the error state of <tt>os</tt>.
+</p>
+</blockquote>
+<p>
+Now the affected functions <tt>vprint_unicode</tt> and <tt>vprint_nonunicode</tt> are specified to behave as 
+formatted output functions (<sref ref="[ostream.formatted.reqmts]"/>), which distinguishes two phases:
+</p>
+<ol>
+<li><p>Output <em>generation</em>, which would call <tt>setstate(ios_base::failbit)</tt> in case of a failure
+(which may throw an exception)</p></li>
+<li><p>The actual output itself, which would call <tt>setstate(ios_base::badbit)</tt> in case of an exception</p></li>
+</ol>
+<p>
+The <tt>vformat</tt> call is obviously part of the first phase (since it generates the output sequence and not
+yet the actual output), and any failure here (such as an exception) would under regular formatted output function 
+rules set <tt>ios_base::failbit</tt> and <em>not</em> <tt>ios_base::badbit</tt> (the latter would indicate a loss 
+of the actual output sequence integrity and is therefore set by the second phase in case of an exception).
+<p/>
+Therefore mentioning <tt>ios_base::badbit</tt> in (3.2) doesn't really make sense, it could only meaningfully 
+refer to <tt>ios_base::failbit</tt> instead.
+</p>
+</discussion>
+
+<resolution>
+<p>
+This wording is relative to <paper num="N4971"/>.
+</p>
+
+<ol>
+<li><p>Modify <sref ref="[ostream.formatted.print]"/> as indicated:</p>
+
+<blockquote>
+<pre>
+void vprint_unicode(ostream&amp; os, string_view fmt, format_args args);
+void vprint_nonunicode(ostream&amp; os, string_view fmt, format_args args);
+</pre>
+<blockquote>
+<p>
+-3- <i>Effects</i>: Behaves as a formatted output function (<sref ref="[ostream.formatted.reqmts]"/>) 
+of <tt>os</tt>, except that:
+</p>
+<ol style="list-style-type: none">
+<li><p>(3.1) &mdash; failure to generate output is reported as specified below, and</p></li>
+<li><p>(3.2) &mdash; any exception thrown by the call to <tt>vformat</tt> is propagated without regard 
+to the value of <tt>os.exceptions()</tt> and without turning on <tt>ios_base::<ins>failbit</ins><del>badbit</del></tt> 
+in the error state of <tt>os</tt>.</p></li>
+</ol>
+<p>
+[&hellip;]
+</p>
+</blockquote>
+</blockquote>
+</li>
+</ol>
+</resolution>
+
+</issue>