<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
<html>
<head><title>C++ Standard Library Active Issues List</title></head>
<body bgcolor="#ffffff" text="#000000">
<table>
<tr>
<td align="left">Doc. no.</td>
<td align="left">N1480 = 03-0063</td>
</tr>
<tr>
<td align="left">Date:</td>
<td align="left">24 Apr 2003</td>
</tr>
<tr>
<td align="left">Project:</td>
<td align="left">Programming Language C++</td>
</tr>
<tr>
<td align="left">Reply to:</td>
<td align="left">Matt Austern &lt;austern@apple.com&gt;</td>
</tr>
</table>
<h1>C++ Standard Library Active Issues List (Revision 26)</h1>
  <p>Reference ISO/IEC IS 14882:1998(E)</p>
  <p>Also see:</p>
  <ul>
      <li>
<a href="lwg-toc.html">Table of Contents</a> for all library issues.</li>
      <li>
<a href="lwg-index.html">Index by Section</a> for all library issues.</li>
      <li>
<a href="lwg-status.html">Index by Status</a> for all library issues.</li>
      <li><a href="lwg-defects.html">Library Defect Reports List</a></li>
      <li><a href="lwg-closed.html">Library Closed Issues List</a></li>
  </ul>
  <p>The purpose of this document is to record the status of issues
  which have come before the Library Working Group (LWG) of the ANSI
  (J16) and ISO (WG21) C++ Standards Committee. Issues represent
  potential defects in the ISO/IEC IS 14882:1998(E) document.  Issues
  are not to be used to request new features or other extensions. </p>

  <p>This document contains only library issues which are actively being
  considered by the Library Working Group. That is, issues which have a
  status of <a href="lwg-active.html#New">New</a>, <a href="lwg-active.html#Open">Open</a>, 
  <a href="lwg-active.html#Ready">Ready</a>, and <a href="lwg-active.html#Review">Review</a>. See
  <a href="lwg-defects.html">Library Defect Reports List</a> for issues considered defects and 
  <a href="lwg-closed.html">Library Closed Issues List</a> for issues considered closed.</p>

  <p>The issues in these lists are not necessarily formal ISO Defect
  Reports (DR's). While some issues will eventually be elevated to
  official Defect Report status, other issues will be disposed of in
  other ways. See <a href="#Status">Issue Status</a>.</p>

  <p>This document is in an experimental format designed for both
  viewing via a world-wide web browser and hard-copy printing. It
  is available as an HTML file for browsing or PDF file for
  printing.</p>

  <p>Prior to Revision 14, library issues lists existed in two slightly
  different versions; a Committee Version and a Public
  Version. Beginning with Revision 14 the two versions were combined
  into a single version.</p>

  <p>This document includes <i>[bracketed italicized notes]</i> as a
  reminder to the LWG of current progress on issues. Such notes are
  strictly unofficial and should be read with caution as they may be
  incomplete or incorrect. Be aware that LWG support for a particular
  resolution can quickly change if new viewpoints or killer examples are
  presented in subsequent discussions.</p>

  <p>For the most current official version of this document see 
  <a href="http://www.dkuug.dk/jtc1/sc22/wg21">http://www.dkuug.dk/jtc1/sc22/wg21</a>.
  Requests for further information about this document should include
  the document number above, reference ISO/IEC 14882:1998(E), and be
  submitted to Information Technology Industry Council (ITI), 1250 Eye
  Street NW, Washington, DC 20005.</p>

  <p>Public information as to how to obtain a copy of the C++ Standard,
  join the standards committee, submit an issue, or comment on an issue
  can be found in the C++ FAQ at <a href="http://www.research.att.com/~austern/csc/faq.html">http://www.research.att.com/~austern/csc/faq.html</a>.
  Public discussion of C++ Standard related issues occurs on <a href="news:comp.std.c%2B%2B">news:comp.std.c++</a>.
  </p>

 <p>For committee members, files available on the committee's private
  web site include the HTML version of the Standard itself. HTML
  hyperlinks from this issues list to those files will only work for
  committee members who have downloaded them into the same disk
  directory as the issues list files.  </p>
<h2>Revision History</h2>
<ul>
<li>R26: 
Post-Oxford mailing: reflects decisions made at the Oxford meeting.
All issues in Ready status were voted into DR status.  All issues in
DR status were voted into WP status.
</li>
<li>R25: 
Pre-Oxford mailing.  Added new issues <a href="lwg-closed.html#390">390</a>-<a href="lwg-active.html#402">402</a>.
</li>
<li>R24: 
Post-Santa Cruz mailing: reflects decisions made at the Santa Cruz
meeting.  All Ready issues from R23 with the exception of <a href="lwg-active.html#253">253</a>, which has been given a new proposed resolution, were
moved to DR status.  Added new issues <a href="lwg-defects.html#383">383</a>-<a href="lwg-active.html#389">389</a>.  (Issues <a href="lwg-active.html#387">387</a>-<a href="lwg-active.html#389">389</a> were discussed
at the meeting.)  Made progress on issues <a href="lwg-defects.html#225">225</a>, <a href="lwg-active.html#226">226</a>, <a href="lwg-defects.html#229">229</a>: <a href="lwg-defects.html#225">225</a> and <a href="lwg-defects.html#229">229</a> have been moved to Ready status, and the only remaining
concerns with <a href="lwg-active.html#226">226</a> involve wording.
</li>
<li>R23: 
Pre-Santa Cruz mailing.  Added new issues <a href="lwg-closed.html#367">367</a>-<a href="lwg-active.html#382">382</a>.
Moved issues in the TC to TC status.
</li>
<li>R22: 
Post-Cura&ccedil;ao mailing.  Added new issues <a href="lwg-active.html#362">362</a>-<a href="lwg-active.html#366">366</a>.
</li>
<li>R21: 
Pre-Cura&ccedil;ao mailing.  Added new issues <a href="lwg-closed.html#351">351</a>-<a href="lwg-closed.html#361">361</a>.
</li>
<li>R20: 
Post-Redmond mailing; reflects actions taken in Redmond.  Added
new issues <a href="lwg-defects.html#336">336</a>-<a href="lwg-closed.html#350">350</a>, of which issues 
<a href="lwg-active.html#347">347</a>-<a href="lwg-closed.html#350">350</a> were added since Redmond, hence
not discussed at the meeting.  

All Ready issues were moved to DR status, with the exception of issues
<a href="lwg-defects.html#284">284</a>, <a href="lwg-defects.html#241">241</a>, and <a href="lwg-closed.html#267">267</a>.

Noteworthy issues discussed at Redmond include 
<a href="lwg-active.html#120">120</a> <a href="lwg-defects.html#202">202</a>, <a href="lwg-active.html#226">226</a>, <a href="lwg-active.html#233">233</a>, 
<a href="lwg-defects.html#270">270</a>, <a href="lwg-active.html#253">253</a>, <a href="lwg-closed.html#254">254</a>, <a href="lwg-closed.html#323">323</a>.
</li>
<li>R19: 
Pre-Redmond mailing.  Added new issues 
<a href="lwg-closed.html#323">323</a>-<a href="lwg-defects.html#335">335</a>.
</li>
<li>R18: 
Post-Copenhagen mailing; reflects actions taken in Copenhagen.
Added new issues <a href="lwg-defects.html#312">312</a>-<a href="lwg-defects.html#317">317</a>, and discussed
new issues <a href="lwg-defects.html#271">271</a>-<a href="lwg-closed.html#314">314</a>.

Changed status of issues
<a href="lwg-defects.html#103">103</a> <a href="lwg-defects.html#118">118</a> <a href="lwg-defects.html#136">136</a> <a href="lwg-defects.html#153">153</a>
<a href="lwg-defects.html#165">165</a> <a href="lwg-defects.html#171">171</a> <a href="lwg-defects.html#183">183</a> <a href="lwg-defects.html#184">184</a>
<a href="lwg-defects.html#185">185</a> <a href="lwg-defects.html#186">186</a> <a href="lwg-defects.html#214">214</a> <a href="lwg-defects.html#221">221</a>
<a href="lwg-defects.html#234">234</a> <a href="lwg-defects.html#237">237</a> <a href="lwg-defects.html#243">243</a> <a href="lwg-defects.html#248">248</a>
<a href="lwg-defects.html#251">251</a> <a href="lwg-defects.html#252">252</a> <a href="lwg-defects.html#256">256</a> <a href="lwg-defects.html#260">260</a>
<a href="lwg-defects.html#261">261</a> <a href="lwg-defects.html#262">262</a> <a href="lwg-defects.html#263">263</a> <a href="lwg-defects.html#265">265</a>
<a href="lwg-defects.html#268">268</a>
to DR.

Changed status of issues
<a href="lwg-defects.html#49">49</a>  <a href="lwg-defects.html#109">109</a> <a href="lwg-defects.html#117">117</a> <a href="lwg-defects.html#182">182</a>
<a href="lwg-defects.html#228">228</a> <a href="lwg-defects.html#230">230</a> <a href="lwg-defects.html#232">232</a> <a href="lwg-defects.html#235">235</a>
<a href="lwg-defects.html#238">238</a> <a href="lwg-defects.html#241">241</a> <a href="lwg-defects.html#242">242</a> <a href="lwg-defects.html#250">250</a>
<a href="lwg-defects.html#259">259</a> <a href="lwg-defects.html#264">264</a> <a href="lwg-defects.html#266">266</a> <a href="lwg-closed.html#267">267</a>
<a href="lwg-defects.html#271">271</a> <a href="lwg-defects.html#272">272</a> <a href="lwg-defects.html#273">273</a> <a href="lwg-defects.html#275">275</a>
<a href="lwg-defects.html#281">281</a> <a href="lwg-defects.html#284">284</a> <a href="lwg-defects.html#285">285</a> <a href="lwg-defects.html#286">286</a>
<a href="lwg-defects.html#288">288</a> <a href="lwg-defects.html#292">292</a> <a href="lwg-defects.html#295">295</a> <a href="lwg-defects.html#297">297</a>
<a href="lwg-defects.html#298">298</a> <a href="lwg-defects.html#301">301</a> <a href="lwg-defects.html#303">303</a> <a href="lwg-defects.html#306">306</a>
<a href="lwg-defects.html#307">307</a> <a href="lwg-defects.html#308">308</a> <a href="lwg-defects.html#312">312</a>
to Ready.

Closed issues 
<a href="lwg-closed.html#111">111</a> <a href="lwg-closed.html#277">277</a> <a href="lwg-closed.html#279">279</a> <a href="lwg-closed.html#287">287</a>
<a href="lwg-closed.html#289">289</a> <a href="lwg-closed.html#293">293</a> <a href="lwg-closed.html#302">302</a> <a href="lwg-closed.html#313">313</a>
<a href="lwg-closed.html#314">314</a>
as NAD.

</li>
<li>R17: 
Pre-Copenhagen mailing.  Converted issues list to XML.  Added proposed
resolutions for issues <a href="lwg-defects.html#49">49</a>, <a href="lwg-defects.html#76">76</a>, <a href="lwg-defects.html#91">91</a>, <a href="lwg-defects.html#235">235</a>, <a href="lwg-defects.html#250">250</a>, <a href="lwg-closed.html#267">267</a>.
Added new issues <a href="lwg-defects.html#278">278</a>-<a href="lwg-defects.html#311">311</a>.
</li>
<li>R16:  
post-Toronto mailing; reflects actions taken in Toronto. Added new
issues <a href="lwg-defects.html#265">265</a>-<a href="lwg-closed.html#277">277</a>.  Changed status of issues
<a href="lwg-defects.html#3">3</a>, <a href="lwg-defects.html#8">8</a>, <a href="lwg-defects.html#9">9</a>, <a href="lwg-defects.html#19">19</a>,
<a href="lwg-defects.html#26">26</a>, <a href="lwg-defects.html#31">31</a>, <a href="lwg-defects.html#61">61</a>,
<a href="lwg-defects.html#63">63</a>, <a href="lwg-defects.html#86">86</a>, <a href="lwg-defects.html#108">108</a>,
<a href="lwg-defects.html#112">112</a>, <a href="lwg-defects.html#114">114</a>, <a href="lwg-defects.html#115">115</a>,
<a href="lwg-defects.html#122">122</a>, <a href="lwg-defects.html#127">127</a>, <a href="lwg-defects.html#129">129</a>,
<a href="lwg-defects.html#134">134</a>, <a href="lwg-defects.html#137">137</a>, <a href="lwg-defects.html#142">142</a>,
<a href="lwg-defects.html#144">144</a>, <a href="lwg-defects.html#146">146</a>, <a href="lwg-defects.html#147">147</a>,
<a href="lwg-defects.html#159">159</a>, <a href="lwg-defects.html#164">164</a>, <a href="lwg-defects.html#170">170</a>,
<a href="lwg-defects.html#181">181</a>, <a href="lwg-defects.html#199">199</a>, <a href="lwg-defects.html#208">208</a>,
<a href="lwg-defects.html#209">209</a>, <a href="lwg-defects.html#210">210</a>, <a href="lwg-defects.html#211">211</a>,
<a href="lwg-defects.html#212">212</a>, <a href="lwg-defects.html#217">217</a>, <a href="lwg-defects.html#220">220</a>,
<a href="lwg-defects.html#222">222</a>, <a href="lwg-defects.html#223">223</a>, <a href="lwg-defects.html#224">224</a>,
<a href="lwg-defects.html#227">227</a> to &quot;DR&quot;.  Reopened issue <a href="lwg-active.html#23">23</a>. Reopened
issue <a href="lwg-defects.html#187">187</a>. Changed issues <a href="lwg-closed.html#2">2</a> and
<a href="lwg-closed.html#4">4</a> to NAD. Fixed a typo in issue <a href="lwg-defects.html#17">17</a>. Fixed
issue <a href="lwg-defects.html#70">70</a>: signature should be changed both places it
appears. Fixed issue <a href="lwg-defects.html#160">160</a>: previous version didn't fix
the bug in enough places.
</li>
<li>R15: 
pre-Toronto mailing. Added issues
<a href="lwg-active.html#233">233</a>-<a href="lwg-defects.html#264">264</a>. Some small HTML formatting
changes so that we pass Weblint tests.
</li>
<li>R14: 
post-Tokyo II mailing; reflects committee actions taken in
Tokyo. Added issues <a href="lwg-defects.html#228">228</a> to <a href="lwg-defects.html#232">232</a>. (00-0019R1/N1242)
</li>
<li>R13: 
pre-Tokyo II updated: Added issues <a href="lwg-defects.html#212">212</a> to <a href="lwg-defects.html#227">227</a>.
</li>
<li>R12: 
pre-Tokyo II mailing: Added issues <a href="lwg-defects.html#199">199</a> to
<a href="lwg-defects.html#211">211</a>. Added &quot;and paragraph 5&quot; to the proposed resolution
of issue <a href="lwg-defects.html#29">29</a>.  Add further rationale to issue
<a href="lwg-closed.html#178">178</a>.
</li>
<li>R11: 
post-Kona mailing: Updated to reflect LWG and full committee actions
in Kona (99-0048/N1224). Note changed resolution of issues
<a href="lwg-closed.html#4">4</a> and <a href="lwg-defects.html#38">38</a>. Added issues <a href="lwg-closed.html#196">196</a>
to <a href="lwg-defects.html#198">198</a>. Closed issues list split into &quot;defects&quot; and
&quot;closed&quot; documents.  Changed the proposed resolution of issue
<a href="lwg-closed.html#4">4</a> to NAD, and changed the wording of proposed resolution
of issue <a href="lwg-defects.html#38">38</a>.
</li>
<li>R10: 
pre-Kona updated.  Added proposed resolutions <a href="lwg-defects.html#83">83</a>,
<a href="lwg-defects.html#86">86</a>, <a href="lwg-defects.html#91">91</a>, <a href="lwg-active.html#92">92</a>,
<a href="lwg-defects.html#109">109</a>. Added issues <a href="lwg-closed.html#190">190</a> to
<a href="lwg-defects.html#195">195</a>. (99-0033/D1209, 14 Oct 99)
</li>
<li>R9: 
pre-Kona mailing.  Added issues <a href="lwg-closed.html#140">140</a> to
<a href="lwg-defects.html#189">189</a>. Issues list split into separate &quot;active&quot; and
&quot;closed&quot; documents. (99-0030/N1206, 25 Aug 99)
</li>
<li>R8: 
post-Dublin mailing. Updated to reflect LWG and full committee actions
in Dublin. (99-0016/N1193, 21 Apr 99)
</li>
<li>R7: 
pre-Dublin updated: Added issues <a href="lwg-closed.html#130">130</a>, <a href="lwg-closed.html#131">131</a>,
<a href="lwg-defects.html#132">132</a>, <a href="lwg-defects.html#133">133</a>, <a href="lwg-defects.html#134">134</a>,
<a href="lwg-closed.html#135">135</a>, <a href="lwg-defects.html#136">136</a>, <a href="lwg-defects.html#137">137</a>,
<a href="lwg-closed.html#138">138</a>, <a href="lwg-defects.html#139">139</a> (31 Mar 99)
</li>
<li>R6: 
pre-Dublin mailing. Added issues <a href="lwg-defects.html#127">127</a>, <a href="lwg-closed.html#128">128</a>,
and <a href="lwg-defects.html#129">129</a>.  (99-0007/N1194, 22 Feb 99)
</li>
<li>R5: 
update issues <a href="lwg-defects.html#103">103</a>, <a href="lwg-defects.html#112">112</a>; added issues
<a href="lwg-defects.html#114">114</a> to <a href="lwg-defects.html#126">126</a>. Format revisions to prepare
for making list public. (30 Dec 98)
</li>
<li>R4: 
post-Santa Cruz II updated: Issues <a href="lwg-defects.html#110">110</a>,
<a href="lwg-closed.html#111">111</a>, <a href="lwg-defects.html#112">112</a>, <a href="lwg-closed.html#113">113</a> added, several
issues corrected. (22 Oct 98)
</li>
<li>R3: 
post-Santa Cruz II: Issues <a href="lwg-closed.html#94">94</a> to <a href="lwg-defects.html#109">109</a>
added, many issues updated to reflect LWG consensus (12 Oct 98)
</li>
<li>R2: 
pre-Santa Cruz II: Issues <a href="lwg-closed.html#73">73</a> to <a href="lwg-closed.html#93">93</a> added,
issue <a href="lwg-defects.html#17">17</a> updated. (29 Sep 98)
</li>
<li>R1: 
Correction to issue <a href="lwg-defects.html#55">55</a> resolution, <a href="lwg-defects.html#60">60</a> code
format, <a href="lwg-defects.html#64">64</a> title. (17 Sep 98)
</li>
</ul>
<h2>
<a name="Status"></a>Issue Status</h2>
  <p>
<b><a name="New">New</a></b> - The issue has not yet been
  reviewed by the LWG. Any <b>Proposed Resolution</b> is purely a
  suggestion from the issue submitter, and should not be construed as
  the view of LWG.</p>

  <p>
<b><a name="Open">Open</a></b> - The LWG has discussed the issue
  but is not yet ready to move the issue forward. There are several
  possible reasons for open status:</p>
     <ul>
        <li>Consensus may have not yet have been reached as to how to deal
            with the issue.</li>
        <li>Informal consensus may have been reached, but the LWG awaits
            exact <b>Proposed Resolution</b> wording for review.</li>
        <li>The LWG wishes to consult additional technical experts before
            proceeding.</li>
        <li>The issue may require further study.</li>
     </ul>

  <p>A <b>Proposed Resolution</b> for an open issue is still not be
  construed as the view of LWG. Comments on the current state of
  discussions are often given at the end of open issues in an italic
  font. Such comments are for information only and should not be given
  undue importance.</p>

  <p>
<b><a name="Dup">Dup</a></b> - The LWG has reached consensus that
  the issue is a duplicate of another issue, and will not be further
  dealt with. A <b>Rationale</b> identifies the duplicated issue's
  issue number.  </p>

  <p>
<b><a name="NAD">NAD</a></b> - The LWG has reached consensus that
  the issue is not a defect in the Standard, and the issue is ready to
  forward to the full committee as a proposed record of response. A
  <b>Rationale</b> discusses the LWG's reasoning.</p>

  <p>
<b><a name="Review">Review</a></b> - Exact wording of a
  <b>Proposed Resolution</b> is now available for review on an issue
  for which the LWG previously reached informal consensus.</p>

  <p>
<b><a name="Ready">Ready</a></b> - The LWG has reached consensus
  that the issue is a defect in the Standard, the <b>Proposed
  Resolution</b> is correct, and the issue is ready to forward to the
  full committee for further action as a Defect Report (DR).</p>

  <p>
<b><a name="DR">DR</a></b> - (Defect Report) - The full J16
  committee has voted to forward the issue to the Project Editor to be
  processed as a Potential Defect Report. The Project Editor reviews
  the issue, and then forwards it to the WG21 Convenor, who returns it
  to the full committee for final disposition. This issues list
  accords the status of DR to all these Defect Reports regardless of
  where they are in that process.</p>

  <p>
<b><a name="TC">TC</a></b> - (Technical Corrigenda) - The full
  WG21 committee has voted to accept the Defect Report's Proposed
  Resolution as a Technical Corrigenda.  Action on this issue is thus
  complete and no further action is possible under ISO rules.</p>

  <p>
<b><a name="WP">WP</a></b> - (Working Paper) - The proposed
  resolution has not been accepted as a Technical Corrigendum, but
  the full WG21 committee has voted to apply the Defect Report's Proposed
  Resolution to the working paper.</p>

  <p>
<b><a name="RR">RR</a></b> - (Record of Response) - The full WG21
  committee has determined that this issue is not a defect in the
  Standard. Action on this issue is thus complete and no further
  action is possible under ISO rules.</p>

  <p>
<b><a name="Future">Future</a></b> - In addition to the regular
  status, the LWG believes that this issue should be revisited at the
  next revision of the standard.  It is usually paired with NAD.</p>

  <p>Issues are always given the status of <a href="lwg-active.html#New">New</a> when
  they first appear on the issues list. They may progress to
  <a href="lwg-active.html#Open">Open</a> or <a href="lwg-active.html#Review">Review</a> while the LWG
  is actively working on them. When the LWG has reached consensus on
  the disposition of an issue, the status will then change to
  <a href="lwg-active.html#Dup">Dup</a>, <a href="lwg-active.html#NAD">NAD</a>, or <a href="lwg-active.html#Ready">Ready</a> as appropriate.  Once the full J16 committee votes to
  forward Ready issues to the Project Editor, they are given the
  status of Defect Report ( <a href="lwg-active.html#DR">DR</a>). These in turn may
  become the basis for Technical Corrigenda (<a href="lwg-active.html#TC">TC</a>),
  or are closed without action other than a Record of Response
  (<a href="lwg-active.html#RR">RR</a> ). The intent of this LWG process is that
  only issues which are truly defects in the Standard move to the
  formal ISO DR status.
  </p>

<h2>Active Issues</h2>
<hr>
<a name="23"><h3>23.&nbsp;Num_get overflow result</h3></a><p>
<b>Section:</b>&nbsp;22.2.2.1.2 <a href="lib-locales.html#lib.facet.num.get.virtuals"> [lib.facet.num.get.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
<p>The current description of numeric input does not account for the
possibility of overflow. This is an implicit result of changing the
description to rely on the definition of scanf() (which fails to
report overflow), and conflicts with the documented behavior of
traditional and current implementations. </p>

<p>Users expect, when reading a character sequence that results in a
value unrepresentable in the specified type, to have an error
reported. The standard as written does not permit this. </p>

<p><b>Further comments from Dietmar:</b></p>

<p>
I don't feel comfortable with the proposed resolution to issue 23: It
kind of simplifies the issue to much. Here is what is going on:
</p>

<p>
Currently, the behavior of numeric overflow is rather counter intuitive
and hard to trace, so I will describe it briefly:
</p>

<ul>
  <li>
    According to 22.2.2.1.2 <a href="lib-locales.html#lib.facet.num.get.virtuals"> [lib.facet.num.get.virtuals]</a>
    paragraph 11 <tt>failbit</tt> is set if <tt>scanf()</tt> would
    return an input error; otherwise a value is converted to the rules
    of <tt>scanf</tt>.
  </li>
  <li> 
    <tt>scanf()</tt> is defined in terms of <tt>fscanf()</tt>. 
  </li>
  <li>
    <tt>fscanf()</tt> returns an input failure if during conversion no
    character matching the conversion specification could be extracted
    before reaching EOF. This is the only reason for <tt>fscanf()</tt>
    to fail due to an input error and clearly does not apply to the case
    of overflow.
  </li>
  <li>
    Thus, the conversion is performed according to the rules of
    <tt>fscanf()</tt> which basically says that <tt>strtod</tt>,
    <tt>strtol()</tt>, etc. are to be used for the conversion.
  </li>
  <li>
    The <tt>strtod()</tt>, <tt>strtol()</tt>, etc. functions consume as
    many matching characters as there are and on overflow continue to
    consume matching characters but also return a value identical to
    the maximum (or minimum for signed types if there was a leading minus)
    value of the corresponding type and set <tt>errno</tt> to <tt>ERANGE</tt>.
  </li>
  <li>
    Thus, according to the current wording in the standard, overflows
    can be detected! All what is to be done is to check <tt>errno</tt>
    after reading an element and, of course, clearing <tt>errno</tt>
    before trying a conversion. With the current wording, it can be
    detected whether the overflow was due to a positive or negative
    number for signed types.
  </li>
</ul>

<p><b>Further discussion from Redmond:</b></p>

<p>The basic problem is that we've defined our behavior,
including our error-reporting behavior, in terms of C90.  However,
C90's method of reporting overflow in scanf is not technically an
&quot;input error&quot;.  The <tt>strto_*</tt> functions are more precise.</p>

<p>There was general consensus that <tt>failbit</tt> should be set
upon overflow.  We considered three options based on this:</p>
<ol>
<li>Set failbit upon conversion error (including overflow), and 
    don't store any value.</li>
<li>Set failbit upon conversion error, and also set <tt>errno</tt> to 
    indicated the precise nature of the error.</li>
<li>Set failbit upon conversion error.  If the error was due to
    overflow, store +-numeric_limits&lt;T&gt;::max() as an
    overflow indication.</li>
</ol>

<p>Straw poll: (1) 5; (2) 0; (3) 8.</p>

<p><b>Further discussion from Santa Cruz:</b></p>

<p>There was some discussion of what the intent of our error
  reporting mechanism was.  There was general agreement on the
  following principles:</p>
<ul>
<li>We want to convert strings to numbers in the same way as the
    C <tt>strto*</tt> functions do.  The same things that those
    functions would consider errors, we consider errors.</li>
<li>Overflow is an error.  Floating-point underflow is not an error.
    1.e-9999999, for example, should be treated as 0.  (A negative
    number whose magnitude is too large is still overflow, and is just
    the same error as a positive number whose magnitude is too large.
    Finally, <tt>strtoul</tt> already specifies what happens if you
    try to convert a sequence beginning with a minus sign into an
    unsigned value.)</li>
<li>Our mechanism for reporting errors is to set failbit.  Our
    mechanism is not errno.  Nothing in the standard should
    require or imply that streams or facets ever set errno.
    (Even if some implementations might have that effect.) </li>
</ul>

<p>The crux of the disagreement was that some people, but not all,
   believed that the design was also based on a fourth principle:
   whenever converstion fails and failbit is set, nothing is to be
   extracted and the value of the variable being extracted into is
   guaranteed to be unchanged.</p>

<p>Some people believe that upon overflow, an implementation should
  &quot;extract&quot; a special value that allows the user to tell that it was
  overflow instead of some other kind of error.  Straw poll: 1 person
  believed the standard should require that, 2 thought it should
  forbid it, and 6 thought the standard should allow but not require
  it.</p>

<p>PJP will provide wording.</p>

<p><b>Proposed resolution:</b></p>
<hr>
<a name="44"><h3>44.&nbsp;Iostreams use operator== on int_type values</h3></a><p>
<b>Section:</b>&nbsp;27 <a href="lib-iostreams.html#lib.input.output"> [lib.input.output]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
<p>Many of the specifications for iostreams specify that character
values or their int_type equivalents are compared using operators ==
or !=, though in other places traits::eq() or traits::eq_int_type is
specified to be used throughout. This is an inconsistency; we should
change uses of == and != to use the traits members instead. </p>
<p><b>Proposed resolution:</b></p>

<p><i>[Kona: Nathan to supply proposed wording]</i></p>

<p><i>[
Tokyo: the LWG reaffirmed that this is a defect, and requires careful
review of clause 27 as the changes are context sensitive.
]</i></p>

<hr>
<a name="92"><h3>92.&nbsp;Incomplete Algorithm Requirements</h3></a><p>
<b>Section:</b>&nbsp;25 <a href="lib-algorithms.html#lib.algorithms"> [lib.algorithms]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Review">Review</a>&nbsp; <b>Submitter:</b>&nbsp;Nico Josuttis&nbsp; <b>Date:</b>&nbsp;29 Sep 1998</p>
<p>The standard does not state, how often a function object is copied,
called, or the order of calls inside an algorithm. This may lead to
surprising/buggy behavior. Consider the following example: </p>

<pre>class Nth {    // function object that returns true for the nth element 
  private: 
    int nth;     // element to return true for 
    int count;   // element counter 
  public: 
    Nth (int n) : nth(n), count(0) { 
    } 
    bool operator() (int) { 
        return ++count == nth; 
    } 
}; 
.... 
// remove third element 
    list&lt;int&gt;::iterator pos; 
    pos = remove_if(coll.begin(),coll.end(),  // range 
                    Nth(3)),                  // remove criterion 
    coll.erase(pos,coll.end()); </pre>

<p>This call, in fact removes the 3rd <b>AND the 6th</b> element. This
happens because the usual implementation of the algorithm copies the
function object internally: </p>

<pre>template &lt;class ForwIter, class Predicate&gt; 
ForwIter std::remove_if(ForwIter beg, ForwIter end, Predicate op) 
{ 
    beg = find_if(beg, end, op); 
    if (beg == end) { 
        return beg; 
    } 
    else { 
        ForwIter next = beg; 
        return remove_copy_if(++next, end, beg, op); 
    } 
} </pre>

<p>The algorithm uses find_if() to find the first element that should
be removed. However, it then uses a copy of the passed function object
to process the resulting elements (if any). Here, Nth is used again
and removes also the sixth element. This behavior compromises the
advantage of function objects being able to have a state. Without any
cost it could be avoided (just implement it directly instead of
calling find_if()). </p>
<p><b>Proposed resolution:</b></p>

<p>Add a new paragraph following 25 <a href="lib-algorithms.html#lib.algorithms"> [lib.algorithms]</a> paragraph 8:</p>
<blockquote>
[Note: Unless otherwise specified, algorithms that take function
objects as arguments are permitted to copy those function objects
freely.  Programmers for whom object identity is important should
consider using a wrapper class that points to a noncopied
implementation object, or some equivalent solution.]
</blockquote>

<p><i>[Dublin: Pete Becker felt that this may not be a defect,
but rather something that programmers need to be educated about.
There was discussion of adding wording to the effect that the number
and order of calls to function objects, including predicates, not
affect the behavior of the function object.]</i></p>

<p><i>[Pre-Kona: Nico comments: It seems the problem is that we don't
have a clear statement of &quot;predicate&quot; in the
standard. People including me seemed to think &quot;a function
returning a Boolean value and being able to be called by an STL
algorithm or be used as sorting criterion or ... is a
predicate&quot;. But a predicate has more requirements: It should
never change its behavior due to a call or being copied. IMHO we have
to state this in the standard. If you like, see section 8.1.4 of my
library book for a detailed discussion.]</i></p>

<p><i>[Kona: Nico will provide wording to the effect that &quot;unless
otherwise specified, the number of copies of and calls to function
objects by algorithms is unspecified&quot;.&nbsp; Consider placing in
25 <a href="lib-algorithms.html#lib.algorithms"> [lib.algorithms]</a> after paragraph 9.]</i></p>

<p><i>[Santa Cruz: The standard doesn't currently guarantee that
  functions object won't be copied, and what isn't forbidden is
  allowed.  It is believed (especially since implementations that were
  written in concert with the standard do make copies of function
  objects) that this was intentional.  Thus, no normative change is
  needed.  What we should put in is a non-normative note suggesting to
  programmers that if they want to guarantee the lack of copying they
  should use something like the <tt>ref</tt> wrapper.]</i></p>

<p><i>[Oxford: Matt provided wording.]</i></p>


<hr>
<a name="96"><h3>96.&nbsp;Vector&lt;bool&gt; is not a container</h3></a><p>
<b>Section:</b>&nbsp;23.2.5 <a href="lib-containers.html#lib.vector.bool"> [lib.vector.bool]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;AFNOR&nbsp; <b>Date:</b>&nbsp;7 Oct 1998</p>
<p>
<tt>vector&lt;bool&gt;</tt> is not a container as its reference and
pointer types are not references and pointers. </p>

<p>Also it forces everyone to have a space optimization instead of a
speed one.</p>

<p>
<b>See also:</b> 99-0008 == N1185 Vector&lt;bool&gt; is
Nonconforming, Forces Optimization Choice.</p>
<p><b>Proposed resolution:</b></p>

<p><i>[In Santa Cruz the LWG felt that this was Not A Defect.]</i></p>

<p><i>[In Dublin many present felt that failure to meet Container
requirements was a defect. There was disagreement as to whether
or not the optimization requirements constituted a defect.]</i></p>

<p><i>[The LWG looked at the following resolutions in some detail:
<br>
&nbsp;&nbsp;&nbsp;&nbsp; * Not A Defect.<br>
&nbsp;&nbsp;&nbsp;&nbsp; * Add a note explaining that vector&lt;bool&gt; does not meet
Container requirements.<br>
&nbsp;&nbsp;&nbsp;&nbsp; * Remove vector&lt;bool&gt;.<br>
&nbsp;&nbsp;&nbsp;&nbsp; * Add a new category of container requirements which
vector&lt;bool&gt; would meet.<br>
&nbsp;&nbsp;&nbsp;&nbsp; * Rename vector&lt;bool&gt;.<br>
<br>
No alternative had strong, wide-spread, support and every alternative
had at least one &quot;over my dead body&quot; response.<br>
<br>
There was also mention of a transition scheme something like (1) add
vector_bool and deprecate vector&lt;bool&gt; in the next standard. (2)
Remove vector&lt;bool&gt; in the following standard.]</i></p>

<p><i>[Modifying container requirements to permit returning proxies
(thus allowing container requirements conforming vector&lt;bool&gt;)
was also discussed.]</i></p>

<p><i>[It was also noted that there is a partial but ugly workaround in
that vector&lt;bool&gt; may be further specialized with a customer
allocator.]</i></p>

<p><i>[Kona: Herb Sutter presented his paper J16/99-0035==WG21/N1211,
vector&lt;bool&gt;: More Problems, Better Solutions. Much discussion
of a two step approach: a) deprecate, b) provide replacement under a
new name.  LWG straw vote on that: 1-favor, 11-could live with, 2-over
my dead body.  This resolution was mentioned in the LWG report to the
full committee, where several additional committee members indicated
over-my-dead-body positions.]</i></p>

<p><i>[Tokyo: Not discussed by the full LWG; no one claimed new
insights and so time was more productively spent on other issues. In
private discussions it was asserted that requirements for any solution
include 1) Increasing the full committee's understanding of the
problem, and 2) providing compiler vendors, authors, teachers, and of
course users with specific suggestions as to how to apply the eventual
solution.]</i></p>

<hr>
<a name="98"><h3>98.&nbsp;Input iterator requirements are badly written</h3></a><p>
<b>Section:</b>&nbsp;24.1.1 <a href="lib-iterators.html#lib.input.iterators"> [lib.input.iterators]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Review">Review</a>&nbsp; <b>Submitter:</b>&nbsp;AFNOR&nbsp; <b>Date:</b>&nbsp;7 Oct 1998</p>
<p>Table 72 in 24.1.1 <a href="lib-iterators.html#lib.input.iterators"> [lib.input.iterators]</a> specifies semantics for
<tt>*r++</tt> of:</p>

<p>&nbsp;&nbsp; <tt>{ T tmp = *r; ++r; return tmp; }</tt>
</p>

<p>There are two problems with this.  First, the return type is
specified to be &quot;T&quot;, as opposed to something like &quot;convertible to T&quot;.
This is too specific: we want to allow *r++ to return an lvalue.</p>

<p>Second, writing the semantics in terms of code misleadingly
suggests that the effects *r++ should precisely replicate the behavior
of this code, including side effects.  (Does this mean that *r++
should invoke the copy constructor exactly as many times as the sample
code above would?) See issue <a href="lwg-defects.html#334">334</a> for a similar
problem.</p>

<p><b>Proposed resolution:</b></p>
In Table 72 in 24.1.1 <a href="lib-iterators.html#lib.input.iterators"> [lib.input.iterators]</a>, change the return type
for <tt>*r++</tt> from <tt>T</tt> to &quot;convertible to T&quot;.
<p><b>Rationale:</b></p>
<p>This issue has two parts: the return type, and the number of times
  the copy constructor is invoked.</p>

<p>The LWG believes the the first part is a real issue.  It's
  inappropriate for the return type to be specified so much more
  precisely for *r++ than it is for *r.  In particular, if r is of
  (say) type <tt>int*</tt>, then *r++ isn't <tt>int</tt>,
  but <tt>int&amp;</tt>.</p>

<p>The LWG does not believe that the number of times the copy
  constructor is invoked is a real issue.  This can vary in any case,
  because of language rules on copy constructor elision.  That's too
  much to read into these semantics clauses.</p>
<hr>
<a name="120"><h3>120.&nbsp;Can an implementor add specializations?</h3></a><p>
<b>Section:</b>&nbsp;17.4.3.1 <a href="lib-intro.html#lib.reserved.names"> [lib.reserved.names]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Review">Review</a>&nbsp; <b>Submitter:</b>&nbsp;Judy Ward&nbsp; <b>Date:</b>&nbsp;15 Dec 1998</p>

<p>The original issue asked whether a library implementor could
specialize standard library templates for built-in types.  (This was
an issue because users are permitted to explicitly instantiate
standard library templates.)</p>

<p>Specializations are no longer a problem, because of the resolution
to core issue 259.  Under the proposed resolution, it will be legal
for a translation unit to contain both a specialization and an
explicit instantiation of the same template, provided that the
specialization comes first.  In such a case, the explicit
instantiation will be ignored.  Further discussion of library issue
120 assumes that the core 259 resolution will be adopted.</p>

<p>However, as noted in lib-7047, one piece of this issue still
remains: what happens if a standard library implementor explicitly
instantiates a standard library templates?  It's illegal for a program
to contain two different explicit instantiations of the same template
for the same type in two different translation units (ODR violation),
and the core working group doesn't believe it is practical to relax
that restriction.</p>

<p>The issue, then, is: are users allowed to explicitly instantiate
standard library templates for non-user defined types?  The status quo
answer is 'yes'.  Changing it to 'no' would give library implementors
more freedom.</p>

<p>This is an issue because, for performance reasons, library
implementors often need to explicitly instantiate standard library
templates.  (for example, std::basic_string&lt;char&gt;)  Does giving
users freedom to explicitly instantiate standard library templates for
non-user defined types make it impossible or painfully difficult for
library implementors to do this?</p>

<p>John Spicer suggests, in lib-8957, that library implementors have a
mechanism they can use for explicit instantiations that doesn't
prevent users from performing their own explicit instantiations: put
each explicit instantiation in its own object file.  (Different
solutions might be necessary for Unix DSOs or MS-Windows DLLs.)  On
some platforms, library implementors might not need to do anything
special: the &quot;undefined behavior&quot; that results from having two
different explicit instantiations might be harmless.</p>

<p><b>Proposed resolution:</b></p>
  <p>Append to 17.4.3.1 <a href="lib-intro.html#lib.reserved.names"> [lib.reserved.names]</a> paragraph 1: </p>
  <blockquote>
    A program may explicitly instantiate any templates in the standard
    library only if the declaration depends on a user-defined name of
    external linkage and the instantiation meets the standard library
    requirements for the original template.
  </blockquote>

<p><b>Rationale:</b></p>
<p>The LWG considered another possible resolution:</p>
<blockquote>
  <p>In light of the resolution to core issue 259, no normative changes
  in the library clauses are necessary.  Add the following non-normative
  note to the end of 17.4.3.1 <a href="lib-intro.html#lib.reserved.names"> [lib.reserved.names]</a> paragraph 1:</p>
  <blockquote>
    [<i>Note:</i> A program may explicitly instantiate standard library
    templates, even when an explicit instantiation does not depend on
    a user-defined name. <i>--end note</i>]
  </blockquote>
</blockquote>

<p>The LWG rejected this because it was believed that it would make
  it unnecessarily difficult for library implementors to write
  high-quality implementations.  A program may not include an
  explicit instantiation of the same template, for the same template
  arguments, in two different translation units.  If users are
  allowed to provide explicit instantiations of Standard Library
  templates for built-in types, then library implementors aren't,
  at least not without nonportable tricks.</p>

<p>The most serious problem is a class template that has writeable
  static member variables.  Unfortunately, such class templates are
  important and, in existing Standard Library implementations, are
  often explicitly specialized by library implementors: locale facets,
  which have a writeable static member variable <tt>id</tt>.  If a
  user's explicit instantiation collided with the implementations
  explicit instantiation, iostream initialization could cause locales
  to be constructed in an inconsistent state.</p>

<p>One proposed implementation technique was for Standard Library
  implementors to provide explicit instantiations in separate object
  files, so that they would not be picked up by the linker when the
  user also provides an explicit instantiation.  However, this
  technique only applies for Standard Library implementations that
  are packaged as static archives.  Most Standard Library
  implementations nowadays are packaged as dynamic libraries, so this
  technique would not apply.</p>

<p>The Committee is now considering standardization of dynamic
  linking.  If there are such changes in the future, it may be
  appropriate to revisit this issue later.</p>
<hr>
<a name="167"><h3>167.&nbsp;Improper use of <tt>traits_type::length()</tt>
</h3></a><p>
<b>Section:</b>&nbsp;27.6.2.5.4 <a href="lib-iostreams.html#lib.ostream.inserters.character"> [lib.ostream.inserters.character]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Review">Review</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar K&uuml;hl&nbsp; <b>Date:</b>&nbsp;20 Jul 1999</p>
<p>Paragraph 4 states that the length is determined using
<tt>traits::length(s)</tt>.  Unfortunately, this function is not
defined for example if the character type is <tt>wchar_t</tt> and the
type of <tt>s</tt> is <tt>char const*</tt>. Similar problems exist if
the character type is <tt>char</tt> and the type of <tt>s</tt> is
either <tt>signed char const*</tt> or <tt>unsigned char
const*</tt>.</p>
<p><b>Proposed resolution:</b></p>
<p>Change 27.6.2.5.4 <a href="lib-iostreams.html#lib.ostream.inserters.character"> [lib.ostream.inserters.character]</a> paragraph 4 from:</p>
<blockquote>
  <p>Effects: Behaves like an formatted inserter (as described in
  lib.ostream.formatted.reqmts) of out. After a sentry object is
  constructed it inserts characters. The number of characters starting
  at s to be inserted is traits::length(s). Padding is determined as
  described in lib.facet.num.put.virtuals. The traits::length(s)
  characters starting at s are widened using out.widen
  (lib.basic.ios.members). The widened characters and any required
  padding are inserted into out. Calls width(0).</p>
</blockquote>
<p>to:</p>
<blockquote>
  <p>Effects: Behaves like an formatted inserter (as described in
  lib.ostream.formatted.reqmts) of out. After a sentry object is
  constructed it inserts <i>n</i> characters starting at <i>s</i>,
  where <i>n</i> is:</p>
  <ul>
  <li>traits::length(s) for the overload where the first argument is of
    type basic_ostream&lt;charT, traits&gt;&amp; and the second is
    of type const charT*, and also for the overload where the first
    argument is of type basic_ostream&lt;char, traits&gt;&amp; and
    the second is of type const char*.</li>
  <li>std::char_traits&lt;char&gt;::length(s) 
    for the overload where the first argument is of type 
    basic_ostream&lt;charT, traits&gt;&amp; and the second is of type
    const char*.</li>
  <li>traits::length(reinterpret_cast&lt;const char*&gt;(s)) 
    for the other two overloads.</li>
  </ul>
  <p>Padding is determined as described in
  lib.facet.num.put.virtuals. The <i>n</i> characters starting at
  <i>s</i> are widened using out.widen (lib.basic.ios.members).  The
  widened characters and any required padding are inserted into
  out. Calls width(0).</p>
</blockquote>

<p><i>[Santa Cruz: Matt supplied new wording]</i></p>

<p><b>Rationale:</b></p>
<p>We have five separate cases.  In two of them we can use the
user-supplied traits class without any fuss.  In the other three we
try to use something as close to that user-supplied class as possible.
In two cases we've got a traits class that's appropriate for
char and what we've got is a const signed char* or a const
unsigned char*; that's close enough so we can just use a reinterpret
cast, and continue to use the user-supplied traits class.  Finally,
there's one case where we just have to give up: where we've got a
traits class for some arbitrary charT type, and we somehow have to
deal with a const char*.  There's nothing better to do but fall back
to char_traits&lt;char&gt;</p>
<hr>
<a name="197"><h3>197.&nbsp;max_size() underspecified</h3></a><p>
<b>Section:</b>&nbsp;20.1.5 <a href="lib-utilities.html#lib.allocator.requirements"> [lib.allocator.requirements]</a>, 23.1 <a href="lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Andy Sawyer&nbsp; <b>Date:</b>&nbsp;21 Oct 1999</p>
<p>Must the value returned by max_size() be unchanged from call to call? </p>

<p>Must the value returned from max_size() be meaningful? </p>

<p>Possible meanings identified in lib-6827: </p>

<p>1) The largest container the implementation can support given &quot;best
case&quot; conditions - i.e. assume the run-time platform is &quot;configured to
the max&quot;, and no overhead from the program itself. This may possibly
be determined at the point the library is written, but certainly no
later than compile time.<br>
<br>
2) The largest container the program could create, given &quot;best case&quot;
conditions - i.e. same platform assumptions as (1), but take into
account any overhead for executing the program itself. (or, roughly
&quot;storage=storage-sizeof(program)&quot;). This does NOT include any resource
allocated by the program. This may (or may not) be determinable at
compile time.<br>
<br>
3) The largest container the current execution of the program could
create, given knowledge of the actual run-time platform, but again,
not taking into account any currently allocated resource. This is
probably best determined at program start-up.<br>
<br>
4) The largest container the current execution program could create at
the point max_size() is called (or more correctly at the point
max_size() returns :-), given it's current environment (i.e. taking
into account the actual currently available resources). This,
obviously, has to be determined dynamically each time max_size() is
called. </p>
<p><b>Proposed resolution:</b></p>
<p>Change 20.1.5 <a href="lib-utilities.html#lib.allocator.requirements"> [lib.allocator.requirements]</a> table 32 max_size() wording from:<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the largest value that can meaningfully be 
passed to X::allocate<br> 
to:<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the value of the largest constant expression
(5.19 <a href="expr.html#expr.const"> [expr.const]</a>) that could ever meaningfully be passed to X::allocate</p>

<p>
Change 23.1 <a href="lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> table 65 max_size() wording from:<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; size() of the largest possible container.<br>
to:<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the value of the largest constant expression
(5.19 <a href="expr.html#expr.const"> [expr.const]</a>) that could ever meaningfully be returned by X::size().
</p>

<p><i>[Kona: The LWG informally discussed this and asked Andy Sawyer to submit
an issue.]</i></p>

<p><i>[Tokyo: The LWG believes (1) above is the intended meaning.]</i></p>

<p><i>[Post-Tokyo: Beman Dawes supplied the above resolution at the
request of the LWG. 21.3.3 <a href="lib-strings.html#lib.string.capacity"> [lib.string.capacity]</a> was not changed because it
references max_size() in 23.1.  The term &quot;compile-time&quot; was
avoided because it is not defined anywhere in the standard (even
though it is used several places in the library clauses).]</i></p>

<p><i>[Copenhagen: Exactly what <tt>max_size</tt> means is still
unclear.  It may have a different meaning as a container member
function than as an allocator member function.  For the latter,
it is probably best thought of as an architectural limit.
Nathan will provide new wording.]</i></p>
<hr>
<a name="201"><h3>201.&nbsp;Numeric limits terminology wrong</h3></a><p>
<b>Section:</b>&nbsp;18.2.1 <a href="lib-support.html#lib.limits"> [lib.limits]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Stephen Cleary&nbsp; <b>Date:</b>&nbsp;21 Dec 1999</p>
<p>
In some places in this section, the terms &quot;fundamental types&quot; and
&quot;scalar types&quot; are used when the term &quot;arithmetic types&quot; is intended.
The current usage is incorrect because void is a fundamental type and
pointers are scalar types, neither of which should have
specializations of numeric_limits.
</p>
<p><b>Proposed resolution:</b></p>
<p>Change 18.2 [lib.support.limits] para 1 from:</p>
<blockquote>

<p>  The headers &lt;limits&gt;, &lt;climits&gt;, and &lt;cfloat&gt; supply characteristics of  implementation-dependent fundamental types (3.9.1).</p>
</blockquote>

<p>to:</p>
<blockquote>

<p>  The headers &lt;limits&gt;, &lt;climits&gt;, and &lt;cfloat&gt; supply characteristics of  implementation-dependent arithmetic types (3.9.1).</p>
</blockquote>

<p>Change 18.2.1 [lib.limits] para 1 from:</p>
<blockquote>

<p>  The numeric_limits component provides a C++ program with information about various  properties of the implementation's representation of the fundamental
types.</p>
</blockquote>

<p>to:</p>
<blockquote>

<p>  The numeric_limits component provides a C++ program with information about various  properties of the implementation's representation of the arithmetic
types.</p>
</blockquote>

<p>Change 18.2.1 [lib.limits] para 2 from:</p>
<blockquote>

<p>  Specializations shall be provided for each fundamental type. . .</p>
</blockquote>

<p>to:</p>
<blockquote>

<p>  Specializations shall be provided for each arithmetic type. . .</p>
</blockquote>

<p>Change 18.2.1 [lib.limits] para 4 from:</p>
<blockquote>

<p>  Non-fundamental standard types. . .</p>
</blockquote>

<p>to:</p>
<blockquote>

<p>  Non-arithmetic standard types. . .</p>
</blockquote>

<p>Change 18.2.1.1 [lib.numeric.limits] para 1 from:</p>
<blockquote>

<p>  The member is_specialized makes it possible to distinguish between fundamental types,  which have specializations, and non-scalar types, which
do not.</p>
</blockquote>

<p>to:</p>
<blockquote>

<p>  The member is_specialized makes it possible to distinguish between arithmetic types,  which have specializations, and non-arithmetic types,
which do not.</p>
</blockquote>

<p><i>[post-Toronto: The opinion of the LWG is that the wording in the
standard, as well as the wording of the proposed resolution, is
flawed.  The term &quot;arithmetic types&quot; is well defined in C
and C++, and it is not clear that the term is being used correctly.
It is also not clear that the term &quot;implementation
dependent&quot; has any useful meaning in this context.  The biggest
problem is that numeric_limits seems to be intended both for built-in
types and for user-defined types, and the standard doesn't make it
clear how numeric_limits applies to each of those cases.  A wholesale
review of numeric_limits is needed.  A paper would be welcome.]</i></p>
<hr>
<a name="226"><h3>226.&nbsp;User supplied specializations or overloads of namespace std function templates</h3></a><p>
<b>Section:</b>&nbsp;17.4.3.1 <a href="lib-intro.html#lib.reserved.names"> [lib.reserved.names]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Review">Review</a>&nbsp; <b>Submitter:</b>&nbsp;Dave Abrahams&nbsp; <b>Date:</b>&nbsp;01 Apr 2000</p>
<p>The issues are:&nbsp;</p>
<p>1. How can a 3rd party library implementor (lib1) write a version of a standard
algorithm which is specialized to work with his own class template?&nbsp;</p>
<p>2. How can another library implementor (lib2) write a generic algorithm which 
will take advantage of the specialized algorithm in lib1?</p>
<p>This appears to be the only viable answer under current language rules:</p>
<blockquote>
  <pre>namespace lib1
{
    // arbitrary-precision numbers using T as a basic unit
    template &lt;class T&gt;
    class big_num { //...
    };
    </pre>
  <pre>    // defining this in namespace std is illegal (it would be an
    // overload), so we hope users will rely on Koenig lookup
    template &lt;class T&gt;
    void swap(big_int&lt;T&gt;&amp;, big_int&lt;T&gt;&amp;);
}</pre>
  <pre>#include &lt;algorithm&gt;
namespace lib2
{
    template &lt;class T&gt;
    void generic_sort(T* start, T* end)
    {
            ...
        // using-declaration required so we can work on built-in types
        using std::swap;
        // use Koenig lookup to find specialized algorithm if available
        swap(*x, *y);
    }
}</pre>
</blockquote>
<p>This answer has some drawbacks. First of all, it makes writing lib2 difficult
and somewhat slippery. The implementor needs to remember to write the
using-declaration, or generic_sort will fail to compile when T is a built-in
type. The second drawback is that the use of this style in lib2 effectively
&quot;reserves&quot; names in any namespace which defines types which may
eventually be used with lib2. This may seem innocuous at first when applied to
names like swap, but consider more ambiguous names like unique_copy() instead.
It is easy to imagine the user wanting to define these names differently in his
own namespace. A definition with semantics incompatible with the standard
library could cause serious problems (see issue <a href="lwg-defects.html#225">225</a>).</p>
<p>Why, you may ask, can't we just partially specialize std::swap()? It's
because the language doesn't allow for partial specialization of function
templates. If you write:</p>
<blockquote>
  <pre>namespace std
{
    template &lt;class T&gt;
    void swap(lib1::big_int&lt;T&gt;&amp;, lib1::big_int&lt;T&gt;&amp;);
}</pre>
</blockquote>
<p>You have just overloaded std::swap, which is illegal under the current
language rules. On the other hand, the following full specialization is legal:</p>
<blockquote>
  <pre>namespace std
{
    template &lt;&gt;
    void swap(lib1::other_type&amp;, lib1::other_type&amp;);
}</pre>
</blockquote>

<p>This issue reflects concerns raised by the &quot;Namespace issue
with specialized swap&quot; thread on comp.lang.c++.moderated. A
similar set of concerns was earlier raised on the boost.org mailing
list and the ACCU-general mailing list.  Also see library reflector
message c++std-lib-7354.</p>

<p>
J. C. van Winkel points out (in c++std-lib-9565) another unexpected
fact: it's impossible to output a container of std::pair's using copy
and an ostream_iterator, as long as both pair-members are built-in or
std:: types.  That's because a user-defined operator&lt;&lt; for (for
example) std::pair&lt;const std::string, int&gt; will not be found:
lookup for operator&lt;&lt; will be performed only in namespace std.
Opinions differed on whether or not this was a defect, and, if so,
whether the defect is that something is wrong with user-defined
functionality and std, or whether it's that the standard library does
not provide an operator&lt;&lt; for std::pair&lt;&gt;.
</p>

<p><b>Proposed resolution:</b></p>

<p>Adopt the wording proposed in Howard Hinnant's paper N1439=03-0021,
&quot;Proposed Resolution To LWG issues 225, 226, 229&quot;.</p>

<p><i>[Tokyo: Summary, &quot;There is no conforming way to extend
std::swap for user defined templates.&quot;&nbsp; The LWG agrees that
there is a problem.&nbsp; Would like more information before
proceeding. This may be a core issue.  Core issue 229 has been opened
to discuss the core aspects of this problem. It was also noted that
submissions regarding this issue have been received from several
sources, but too late to be integrated into the issues list.
]</i></p>

<p><i>[Post-Tokyo: A paper with several proposed resolutions,
J16/00-0029==WG21/N1252, &quot;Shades of namespace std functions
&quot; by Alan Griffiths, is in the Post-Tokyo mailing. It
should be considered a part of this issue.]</i></p>

<p><i>[Toronto: Dave Abrahams and Peter Dimov have proposed a
resolution that involves core changes: it would add partial
specialization of function template.  The Core Working Group is
reluctant to add partial specialization of function templates.  It is
viewed as a large change, CWG believes that proposal presented leaves
some syntactic issues unanswered; if the CWG does add partial
specialization of function templates, it wishes to develop its own
proposal.  The LWG continues to believe that there is a serious
problem: there is no good way for users to force the library to use
user specializations of generic standard library functions, and in
certain cases (e.g. transcendental functions called by
<tt>valarray</tt> and <tt>complex</tt>) this is important.  Koenig
lookup isn't adequate, since names within the library must be
qualified with <tt>std</tt> (see issue 225), specialization doesn't
work (we don't have partial specialization of function templates), and
users aren't permitted to add overloads within namespace std.
]</i></p>

<p><i>[Copenhagen: Discussed at length, with no consensus.  Relevant
papers in the pre-Copenhagen mailing: N1289, N1295, N1296.  Discussion
focused on four options. (1) Relax restrictions on overloads within
namespace std. (2) Mandate that the standard library use unqualified
calls for <tt>swap</tt> and possibly other functions.  (3) Introduce
helper class templates for <tt>swap</tt> and possibly other functions.
(4) Introduce partial specialization of function templates.  Every
option had both support and opposition.  Straw poll (first number is
support, second is strongly opposed): (1) 6, 4; (2) 6, 7; (3) 3, 8;
(4) 4, 4.]</i></p>

<p><i>[Redmond: Discussed, again no consensus.  Herb presented an
argument that a user who is defining a type <tt>T</tt> with an
associated <tt>swap</tt> should not be expected to put that
<tt>swap</tt> in namespace std, either by overloading or by partial
specialization.  The argument is that <tt>swap</tt> is part of
<tt>T</tt>'s interface, and thus should to in the same namespace as
<tt>T</tt> and only in that namespace.  If we accept this argument,
the consequence is that standard library functions should use
unqualified call of <tt>swap</tt>.  (And which other functions? Any?)
A small group (Nathan, Howard, Jeremy, Dave, Matt, Walter, Marc) will
try to put together a proposal before the next meeting.]</i></p>

<p><i>[Cura&ccedil;ao: An LWG-subgroup spent an afternoon working on issues
225, 226, and 229.  Their conclusion was that the issues should be
separated into an LWG portion (Howard's paper, N1387=02-0045), and a
EWG portion (Dave will write a proposal). The LWG and EWG had
(separate) discussions of this plan the next day.  The proposed
resolution is the one proposed by Howard.]</i></p>

<p><i>[Santa Cruz: the LWG agreed with the general direction of
  Howard's paper, N1387.  (Roughly: Koenig lookup is disabled unless
  we say otherwise; this issue is about when we do say otherwise.)
  However, there were concerns about wording.  Howard will provide new
  wording.  Bill and Jeremy will review it.]</i></p>

<p><i>[Oxford: Howard proposed the new wording.]</i></p>

<p><b>Rationale:</b></p>
<p>Informally: introduce a Swappable concept, and specify that the
  value types of the iterators passed to certain standard algorithms
  (such as iter_swap, swap_ranges, reverse, rotate, and sort) conform
  to that concept.  The Swappable concept will make it clear that
  these algorithms use unqualified lookup for the calls
  to <tt>swap</tt>.  Also, in 26.3.3.3 <a href="lib-numerics.html#lib.valarray.transcend"> [lib.valarray.transcend]</a> paragraph 1,
  state that the valarray transcendentals use unqualified lookup.</p>
<hr>
<a name="233"><h3>233.&nbsp;Insertion hints in associative containers</h3></a><p>
<b>Section:</b>&nbsp;23.1.2 <a href="lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Andrew Koenig&nbsp; <b>Date:</b>&nbsp;30 Apr 2000</p>
<p>
If <tt>mm</tt> is a multimap and <tt>p</tt> is an iterator
into the multimap, then <tt>mm.insert(p, x)</tt> inserts
<tt>x</tt> into <tt>mm</tt> with <tt>p</tt> as a hint as
to where it should go.  Table 69 claims that the execution time is
amortized constant if the insert winds up taking place adjacent to
<tt>p</tt>, but does not say when, if ever, this is guaranteed to
happen.  All it says it that <tt>p</tt> is a hint as to where to
insert.
</p>
<p>
The question is whether there is any guarantee about the relationship
between <tt>p</tt> and the insertion point, and, if so, what it
is.
</p>
<p>
I believe the present state is that there is no guarantee: The user
can supply <tt>p</tt>, and the implementation is allowed to
disregard it entirely.
</p>

<p>
<b>Additional comments from Nathan:</b><br>

The vote [in Redmond] was on whether to elaborately specify the use of
the hint, or to require behavior only if the value could be inserted
adjacent to the hint.  I would like to ensure that we have a chance to
vote for a deterministic treatment: &quot;before, if possible, otherwise
after, otherwise anywhere appropriate&quot;, as an alternative to the
proposed &quot;before or after, if possible, otherwise [...]&quot;.
</p>


<p><b>Proposed resolution:</b></p>

<p>In table 69 &quot;Associative Container Requirements&quot; in 23.1.2 <a href="lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a>, in the row for <tt>a.insert(p, t)</tt>,
change</p>

<blockquote>
iterator p is a hint pointing to where the insert
should start to search.
</blockquote>

<p>to</p>

<blockquote>
insertion adjacent to iterator p is preferred if
more than one insertion point is valid.
</blockquote>

<p>and change</p>

<blockquote>
logarithmic in general, but amortized constant if
t is inserted right after p.
</blockquote>

<p>to</p>

<blockquote>
logarithmic in general, but amortized constant if
t is inserted adjacent to iterator p.
</blockquote>

<p><i>[Toronto: there was general agreement that this is a real defect:
when inserting an element x into a multiset that already contains
several copies of x, there is no way to know whether the hint will be
used.  The proposed resolution was that the new element should always
be inserted as close to the hint as possible.  So, for example, if
there is a subsequence of equivalent values, then providing a.begin()
as the hint means that the new element should be inserted before the
subsequence even if a.begin() is far away.  JC van Winkel supplied
precise wording for this proposed resolution, and also for an
alternative resolution in which hints are only used when they are
adjacent to the insertion point.]</i></p>

<p><i>[Copenhagen: the LWG agreed to the original proposed resolution,
in which an insertion hint would be used even when it is far from the
insertion point.  This was contingent on seeing a reference
implementation showing that it is possible to implement this
requirement without loss of efficiency.  John Potter provided such a
reference implementation.]</i></p>

<p><i>[Redmond: The LWG was reluctant to adopt the proposal that
emerged from Copenhagen: it seemed excessively complicated, and went
beyond fixing the defect that we identified in Toronto.  PJP provided
the new wording described in this issue.  Nathan agrees that we
shouldn't adopt the more detailed semantics, and notes: &quot;we know that
you can do it efficiently enough with a red-black tree, but there are
other (perhaps better) balanced tree techniques that might differ
enough to make the detailed semantics hard to satisfy.&quot;]</i></p>

<p><i>[Cura&ccedil;ao: Nathan should give us the alternative wording he
suggests so the LWG can decide between the two options.]</i></p>

<hr>
<a name="247"><h3>247.&nbsp;<tt>vector</tt>, <tt>deque::insert</tt> complexity</h3></a><p>
<b>Section:</b>&nbsp;23.2.4.3 <a href="lib-containers.html#lib.vector.modifiers"> [lib.vector.modifiers]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Lisa Lippincott&nbsp; <b>Date:</b>&nbsp;06 June 2000</p>
<p>Paragraph 2 of 23.2.4.3 [lib.vector.modifiers] describes the complexity
of <tt>vector::insert</tt>:</p>

   <blockquote>
   Complexity: If first and last are forward iterators, bidirectional
   iterators, or random access iterators, the complexity is linear in
   the number of elements in the range [first, last) plus the distance
   to the end of the vector. If they are input iterators, the complexity
   is proportional to the number of elements in the range [first, last)
   times the distance to the end of the vector.
   </blockquote>

<p>First, this fails to address the non-iterator forms of
<tt>insert</tt>.</p>

<p>Second, the complexity for input iterators misses an edge case --
it requires that an arbitrary number of elements can be added at
the end of a <tt>vector</tt> in constant time.</p>

<p>At the risk of strengthening the requirement, I suggest simply</p>

   <blockquote>
   Complexity: The complexity is linear in the number of elements 
   inserted plus the distance to the end of the vector.
   </blockquote>

<p>For input iterators, one may achieve this complexity by first
inserting at the end of the <tt>vector</tt>, and then using
<tt>rotate</tt>.</p>

<p>I looked to see if <tt>deque</tt> had a similar problem, and was
surprised to find that <tt>deque</tt> places no requirement on the
complexity of inserting multiple elements (23.2.1.3 <a href="lib-containers.html#lib.deque.modifiers"> [lib.deque.modifiers]</a>,
paragraph 3):</p>

   <blockquote>
   Complexity: In the worst case, inserting a single element into a
   deque takes time linear in the minimum of the distance from the
   insertion point to the beginning of the deque and the distance
   from the insertion point to the end of the deque. Inserting a
   single element either at the beginning or end of a deque always
   takes constant time and causes a single call to the copy constructor
   of T.
   </blockquote>

<p>I suggest:</p>

   <blockquote>
   Complexity: The complexity is linear in the number of elements 
   inserted plus the shorter of the distances to the beginning and
   end of the deque.  Inserting a single element at either the
   beginning or the end of a deque causes a single call to the copy
   constructor of T.
   </blockquote>
<p><b>Proposed resolution:</b></p>

<p><i>[Toronto: It's agreed that there is a defect in complexity of
multi-element insert for vector and deque.  For vector, the complexity
should probably be something along the lines of <tt>c<sub>1</sub> * N
+ c<sub>2</sub> * distance(i, end())</tt>.  However, there is some
concern about whether it is reasonable to amortize away the copies
that we get from a reallocation whenever we exceed the vector's
capacity.  For deque, the situation is somewhat less clear.  Deque is
notoriously complicated, and we may not want to impose complexity
requirements that would imply any implementation technique more
complicated than a while loop whose body is a single-element
insert.]</i></p>
<hr>
<a name="253"><h3>253.&nbsp;valarray helper functions are almost entirely useless</h3></a><p>
<b>Section:</b>&nbsp;26.3.2.1 <a href="lib-numerics.html#lib.valarray.cons"> [lib.valarray.cons]</a>, 26.3.2.2 <a href="lib-numerics.html#lib.valarray.assign"> [lib.valarray.assign]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Review">Review</a>&nbsp; <b>Submitter:</b>&nbsp;Robert Klarer&nbsp; <b>Date:</b>&nbsp;31 Jul 2000</p>
<p>This discussion is adapted from message c++std-lib-7056 posted
November 11, 1999.  I don't think that anyone can reasonably claim
that the problem described below is NAD.</p>

<p>These valarray constructors can never be called:</p>

<pre>
   template &lt;class T&gt;
         valarray&lt;T&gt;::valarray(const slice_array&lt;T&gt; &amp;);
   template &lt;class T&gt;
         valarray&lt;T&gt;::valarray(const gslice_array&lt;T&gt; &amp;);
   template &lt;class T&gt;
         valarray&lt;T&gt;::valarray(const mask_array&lt;T&gt; &amp;);
   template &lt;class T&gt;
         valarray&lt;T&gt;::valarray(const indirect_array&lt;T&gt; &amp;);
</pre>

<p>Similarly, these valarray assignment operators cannot be
called:</p>

<pre>
     template &lt;class T&gt;
     valarray&lt;T&gt; valarray&lt;T&gt;::operator=(const slice_array&lt;T&gt; &amp;);
     template &lt;class T&gt;
     valarray&lt;T&gt; valarray&lt;T&gt;::operator=(const gslice_array&lt;T&gt; &amp;);
     template &lt;class T&gt;
     valarray&lt;T&gt; valarray&lt;T&gt;::operator=(const mask_array&lt;T&gt; &amp;);
     template &lt;class T&gt;
     valarray&lt;T&gt; valarray&lt;T&gt;::operator=(const indirect_array&lt;T&gt; &amp;);
</pre>

<p>Please consider the following example:</p>

<pre>
   #include &lt;valarray&gt;
   using namespace std;

   int main()
   {
       valarray&lt;double&gt; va1(12);
       valarray&lt;double&gt; va2(va1[slice(1,4,3)]); // line 1
   }
</pre>


<p>Since the valarray va1 is non-const, the result of the sub-expression
va1[slice(1,4,3)] at line 1 is an rvalue of type const
std::slice_array&lt;double&gt;.  This slice_array rvalue is then used to
construct va2.  The constructor that is used to construct va2 is
declared like this:</p>

<pre>
     template &lt;class T&gt;
     valarray&lt;T&gt;::valarray(const slice_array&lt;T&gt; &amp;);
</pre>

<p>Notice the constructor's const reference parameter.  When the
constructor is called, a slice_array must be bound to this reference.
The rules for binding an rvalue to a const reference are in 8.5.3,
paragraph 5 (see also 13.3.3.1.4).  Specifically, paragraph 5
indicates that a second slice_array rvalue is constructed (in this
case copy-constructed) from the first one; it is this second rvalue
that is bound to the reference parameter.  Paragraph 5 also requires
that the constructor that is used for this purpose be callable,
regardless of whether the second rvalue is elided.  The
copy-constructor in this case is not callable, however, because it is
private.  Therefore, the compiler should report an error.</p>

<p>Since slice_arrays are always rvalues, the valarray constructor that has a
parameter of type const slice_array&lt;T&gt; &amp; can never be called.  The
same reasoning applies to the three other constructors and the four
assignment operators that are listed at the beginning of this post.
Furthermore, since these functions cannot be called, the valarray helper
classes are almost entirely useless.</p>
<p><b>Proposed resolution:</b></p>
<p>slice_array:</p>
<ul>
<li> Make the copy constructor and copy-assignment operator declarations
     public in the slice_array class template definition in 26.3.5 <a href="lib-numerics.html#lib.template.slice.array"> [lib.template.slice.array]</a> </li>
<li> remove paragraph 3 of 26.3.5 <a href="lib-numerics.html#lib.template.slice.array"> [lib.template.slice.array]</a>
</li>
<li> remove the copy constructor declaration from 26.3.5.1 <a href="lib-numerics.html#lib.cons.slice.arr"> [lib.cons.slice.arr]</a>
</li>
<li> change paragraph 1 of 26.3.5.1 <a href="lib-numerics.html#lib.cons.slice.arr"> [lib.cons.slice.arr]</a> to read &quot;This constructor is declared
    to be private.  This constructor need not be defined.&quot;</li>
<li> remove the first sentence of paragraph 1 of 26.3.5.2 <a href="lib-numerics.html#lib.slice.arr.assign"> [lib.slice.arr.assign]</a>
</li>
<li> Change the first three words of the second sentence of paragraph 1 of
    26.3.5.2 <a href="lib-numerics.html#lib.slice.arr.assign"> [lib.slice.arr.assign]</a> to &quot;These assignment operators have&quot;</li>
</ul>

<p>gslice_array:</p>
<ul>
<li> Make the copy constructor and copy-assignment operator declarations
    public in the gslice_array class template definition in 26.3.7 <a href="lib-numerics.html#lib.template.gslice.array"> [lib.template.gslice.array]</a> </li>
<li> remove the note in paragraph 3 of 26.3.7 <a href="lib-numerics.html#lib.template.gslice.array"> [lib.template.gslice.array]</a>
</li>
<li> remove the copy constructor declaration from 26.3.7.1 <a href="lib-numerics.html#lib.gslice.array.cons"> [lib.gslice.array.cons]</a>
</li>
<li> change paragraph 1 of 26.3.7.1 <a href="lib-numerics.html#lib.gslice.array.cons"> [lib.gslice.array.cons]</a> to read &quot;This constructor is declared
    to be private.  This constructor need not be defined.&quot;</li>
<li> remove the first sentence of paragraph 1 of 26.3.7.2 <a href="lib-numerics.html#lib.gslice.array.assign"> [lib.gslice.array.assign]</a>
</li>
<li> Change the first three words of the second sentence of paragraph 1 of
    26.3.7.2 <a href="lib-numerics.html#lib.gslice.array.assign"> [lib.gslice.array.assign]</a> to &quot;These assignment operators have&quot;</li>
</ul>

<p>mask_array:</p>
<ul>
<li> Make the copy constructor and copy-assignment operator declarations
    public in the mask_array class template definition in 26.3.8 <a href="lib-numerics.html#lib.template.mask.array"> [lib.template.mask.array]</a> </li>
<li> remove the note in paragraph 2 of 26.3.8 <a href="lib-numerics.html#lib.template.mask.array"> [lib.template.mask.array]</a>
</li>
<li> remove the copy constructor declaration from 26.3.8.1 <a href="lib-numerics.html#lib.mask.array.cons"> [lib.mask.array.cons]</a>
</li>
<li> change paragraph 1 of 26.3.8.1 <a href="lib-numerics.html#lib.mask.array.cons"> [lib.mask.array.cons]</a> to read &quot;This constructor is declared
    to be private.  This constructor need not be defined.&quot;</li>
<li> remove the first sentence of paragraph 1 of 26.3.8.2 <a href="lib-numerics.html#lib.mask.array.assign"> [lib.mask.array.assign]</a>
</li>
<li> Change the first three words of the second sentence of paragraph 1 of
    26.3.8.2 <a href="lib-numerics.html#lib.mask.array.assign"> [lib.mask.array.assign]</a> to &quot;These assignment operators have&quot;</li>
</ul>

<p>indirect_array:</p>
<ul>
<li>Make the copy constructor and copy-assignment operator declarations
    public in the indirect_array class definition in 26.3.9 <a href="lib-numerics.html#lib.template.indirect.array"> [lib.template.indirect.array]</a>
</li>
<li> remove the note in paragraph 2 of 26.3.9 <a href="lib-numerics.html#lib.template.indirect.array"> [lib.template.indirect.array]</a>
</li>
<li> remove the copy constructor declaration from 26.3.9.1 <a href="lib-numerics.html#lib.indirect.array.cons"> [lib.indirect.array.cons]</a>
</li>
<li> change the descriptive text in 26.3.9.1 <a href="lib-numerics.html#lib.indirect.array.cons"> [lib.indirect.array.cons]</a> to read &quot;This constructor is
    declared to be private.  This constructor need not be defined.&quot;</li>
<li> remove the first sentence of paragraph 1 of 26.3.9.2 <a href="lib-numerics.html#lib.indirect.array.assign"> [lib.indirect.array.assign]</a>
</li>
<li> Change the first three words of the second sentence of paragraph 1 of
    26.3.9.2 <a href="lib-numerics.html#lib.indirect.array.assign"> [lib.indirect.array.assign]</a> to &quot;These assignment operators have&quot;</li>
</ul>
<p><i>[Proposed resolution was modified in Santa Cruz: explicitly make
copy constructor and copy assignment operators public, instead of
removing them.]</i></p>
<p><b>Rationale:</b></p>
<p>Keeping the valarray constructors private is untenable.  Merely
making valarray a friend of the helper classes isn't good enough,
because access to the copy constructor is checked in the user's
environment.</p>

<p>Making the assignment operator public is not strictly necessary to
solve this problem.  A majority of the LWG <i>(straw poll: 13-4)</i>
believed we should make the assignment operators public, in addition
to the copy constructors, for reasons of symmetry and user
expectation.</p>
<hr>
<a name="258"><h3>258.&nbsp;Missing allocator requirement</h3></a><p>
<b>Section:</b>&nbsp;20.1.5 <a href="lib-utilities.html#lib.allocator.requirements"> [lib.allocator.requirements]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;22 Aug 2000</p>
<p>
From lib-7752:
</p>

<p>
I've been assuming (and probably everyone else has been assuming) that
allocator instances have a particular property, and I don't think that
property can be deduced from anything in Table 32.
</p>

<p>
I think we have to assume that allocator type conversion is a
homomorphism.  That is, if x1 and x2 are of type X, where
X::value_type is T, and if type Y is X::template
rebind&lt;U&gt;::other, then Y(x1) == Y(x2) if and only if x1 == x2.
</p>

<p>
Further discussion: Howard Hinnant writes, in lib-7757:
</p>

<p>
I think I can prove that this is not provable by Table 32.  And I agree 
it needs to be true except for the &quot;and only if&quot;.  If x1 != x2, I see no 
reason why it can't be true that Y(x1) == Y(x2).  Admittedly I can't 
think of a practical instance where this would happen, or be valuable.  
But I also don't see a need to add that extra restriction.  I think we 
only need:
</p>

<blockquote>
     if (x1 == x2) then Y(x1) == Y(x2)
</blockquote>

<p>
If we decide that == on allocators is transitive, then I think I can 
prove the above.  But I don't think == is necessarily transitive on 
allocators.  That is:
</p>

<p>
Given x1 == x2  and x2 == x3, this does not mean x1 == x3.
</p>

<p>Example:</p>

<blockquote>
<p>
x1 can deallocate pointers from:  x1, x2, x3    <br>
x2 can deallocate pointers from:  x1, x2, x4    <br>
x3 can deallocate pointers from:  x1, x3        <br>
x4 can deallocate pointers from:  x2, x4 
</p>

<p>
x1 == x2, and x2 == x4, but x1 != x4
</p>
</blockquote>
<p><b>Proposed resolution:</b></p>

<p><i>[Toronto: LWG members offered multiple opinions.  One
opinion is that it should not be required that <tt>x1 == x2</tt>
implies <tt>Y(x1) == Y(x2)</tt>, and that it should not even be
required that <tt>X(x1) == x1</tt>.  Another opinion is that 
the second line from the bottom in table 32 already implies the
desired property.  This issue should be considered in light of
other issues related to allocator instances.]</i></p>
<hr>
<a name="280"><h3>280.&nbsp;Comparison of reverse_iterator to const reverse_iterator</h3></a><p>
<b>Section:</b>&nbsp;24.4.1 <a href="lib-iterators.html#lib.reverse.iterators"> [lib.reverse.iterators]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Steve Cleary&nbsp; <b>Date:</b>&nbsp;27 Nov 2000</p>
<p>
This came from an email from Steve Cleary to Fergus in reference to
issue <a href="lwg-defects.html#179">179</a>. The library working group briefly discussed
this in Toronto and believed it should be a separate issue.  There was
also some reservations about whether this was a worthwhile problem to
fix.
</p>

<p>
Steve said: &quot;Fixing reverse_iterator. std::reverse_iterator can
(and should) be changed to preserve these additional
requirements.&quot; He also said in email that it can be done without
breaking user's code: &quot;If you take a look at my suggested
solution, reverse_iterator doesn't have to take two parameters; there
is no danger of breaking existing code, except someone taking the
address of one of the reverse_iterator global operator functions, and
I have to doubt if anyone has ever done that. . .  <i>But</i>, just in
case they have, you can leave the old global functions in as well --
they won't interfere with the two-template-argument functions.  With
that, I don't see how <i>any</i> user code could break.&quot;
</p>
<p><b>Proposed resolution:</b></p>
<p>
<b>Section:</b> 24.4.1.1 <a href="lib-iterators.html#lib.reverse.iterator"> [lib.reverse.iterator]</a>
add/change the following declarations:</p>
<pre>
  A) Add a templated assignment operator, after the same manner
        as the templated copy constructor, i.e.:

  template &lt; class U &gt;
  reverse_iterator &lt; Iterator &gt;&amp; operator=(const reverse_iterator&lt; U &gt;&amp; u);

  B) Make all global functions (except the operator+) have
  two template parameters instead of one, that is, for
  operator ==, !=, &lt;, &gt;, &lt;=, &gt;=, - replace:

       template &lt; class Iterator &gt;
       typename reverse_iterator&lt; Iterator &gt;::difference_type operator-(
                 const reverse_iterator&lt; Iterator &gt;&amp; x,
                 const reverse_iterator&lt; Iterator &gt;&amp; y);

  with:

      template &lt; class Iterator1, class Iterator2 &gt;
      typename reverse_iterator &lt; Iterator1 &gt;::difference_type operator-(
                 const reverse_iterator &lt; Iterator1 &gt; &amp; x,
                 const reverse_iterator &lt; Iterator2 &gt; &amp; y);
</pre>
<p>
Also make the addition/changes for these signatures in 
24.4.1.3 <a href="lib-iterators.html#lib.reverse.iter.ops"> [lib.reverse.iter.ops]</a>.
</p>

<p><i>[
Copenhagen: The LWG is concerned that the proposed resolution 
introduces new overloads.  Experience shows that introducing
overloads is always risky, and that it would be inappropriate to
make this change without implementation experience.  It may be
desirable to provide this feature in a different way.
]</i></p>

<hr>
<a name="283"><h3>283.&nbsp;std::replace() requirement incorrect/insufficient</h3></a><p>
<b>Section:</b>&nbsp;25.2.4 <a href="lib-algorithms.html#lib.alg.replace"> [lib.alg.replace]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Review">Review</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;15 Dec 2000</p>
<p>
(revision of the further discussion)
There are a number of problems with the requires clauses for the
algorithms in 25.1 and 25.2. The requires clause of each algorithm
should describe the necessary and sufficient requirements on the inputs
to the algorithm such that the algorithm compiles and runs properly.
Many of the requires clauses fail to do this. Here is a summary of the kinds
of mistakes:
</p>

<ol>
<li>
Use of EqualityComparable, which only puts requirements on a single
type, when in fact an equality operator is required between two
different types, typically either T and the iterator's value type
or between the value types of two different iterators.
</li>
<li>
Use of Assignable for T when in fact what was needed is Assignable
for the value_type of the iterator, and convertability from T to the
value_type of the iterator. Or for output iterators, the requirement
should be that T is writable to the iterator (output iterators do
not have value types).
</li>
</ol>

<p>
Here is the list of algorithms that contain mistakes:
</p>

<ul>
<li>25.1.2 std::find</li>
<li>25.1.6 std::count</li>
<li>25.1.8 std::equal</li>
<li>25.1.9 std::search, std::search_n</li>
<li>25.2.4 std::replace, std::replace_copy</li>
<li>25.2.5 std::fill</li>
<li>25.2.7 std::remove, std::remove_copy</li>
</ul>

<p>
Also, in the requirements for EqualityComparable, the requirement that
the operator be defined for const objects is lacking.
</p>

<p><b>Proposed resolution:</b></p>

<p>20.1.1 Change p1 from</p>

<p>In Table 28, <tt>T</tt> is a type to be supplied by a C++ program
instantiating a template, <tt>a</tt>, <tt>b</tt>, and <tt>c</tt> are
values of type <tt>T</tt>.
</p>

<p>to</p>

<p>
In Table 28, <tt>T</tt> is a type to be supplied by a C++ program
instantiating a template, <tt>a</tt>, <tt>b</tt>, and <tt>c</tt> are
values of type <tt>const T</tt>.
</p>

<p>25 Between p8 and p9</p>

<p>Add the following sentence:</p>

<p>When the description of an algorithm gives an expression such as
<tt>*first == value</tt> for a condition, it is required that the expression
evaluate to either true or false in boolean contexts.</p>

<p>25.1.2 Change p1 by deleting the requires clause.</p>

<p>25.1.6 Change p1 by deleting the requires clause.</p>

<p>25.1.9</p>

<p>Change p4 from</p>

<p>-4- Requires: Type <tt>T</tt> is <tt>EqualityComparable</tt>
(20.1.1), type Size is convertible to integral type (4.7.12.3).
</p>

<p>to</p>

<p>-4- Requires: The type <tt>Size</tt> is convertible to integral
type (4.7.12.3).</p>

<p>25.2.4 Change p1 from</p>

<p>-1- Requires: Type <tt>T</tt> is <tt>Assignable</tt> (23.1 ) (and, for <tt>replace()</tt>, <tt>EqualityComparable</tt> (20.1.1 )).</p>

<p>to</p>

<p>-1- Requires: The expression <tt>*first = new_value</tt> must be valid.</p>

<p>and change p4 from</p>

<p>-4- Requires: Type <tt>T</tt> is <tt>Assignable</tt> (23.1) (and,
for <tt>replace_copy()</tt>, <tt>EqualityComparable</tt>
(20.1.1)). The ranges <tt>[first, last)</tt> and <tt>[result, result +
(last - first))</tt> shall not overlap.</p>

<p>to</p>

<p>-4- Requires: The results of the expressions <tt>*first</tt> and
<tt>new_value</tt> must be writable to the result output iterator. The
ranges <tt>[first, last)</tt> and <tt>[result, result + (last -
first))</tt> shall not overlap.</p>


<p>25.2.5 Change p1 from</p>

<p>-1- Requires: Type <tt>T</tt> is <tt>Assignable</tt> (23.1). The
type <tt>Size</tt> is convertible to an integral type (4.7.12.3).</p>

<p>to</p>

<p>-1- Requires: The expression <tt>value</tt> must be is writable to
the output iterator. The type <tt>Size</tt> is convertible to an
integral type (4.7.12.3).</p>

<p>25.2.7 Change p1 from</p>

<p>-1- Requires: Type <tt>T</tt> is <tt>EqualityComparable</tt> (20.1.1).</p>

<p>to</p>

<p>
-1- Requires: The value type of the iterator must be
<tt>Assignable</tt> (23.1).
</p>

<p><b>Rationale:</b></p>
<p>
The general idea of the proposed solution is to remove the faulty
requires clauses and let the returns and effects clauses speak for
themselves. That is, the returns clauses contain expressions that must
be valid, and therefore already imply the correct requirements. In
addition, a sentence is added at the beginning of chapter 25 saying
that expressions given as conditions must evaluate to true or false in
a boolean context. An alternative would be to say that the type of
these condition expressions must be literally bool, but that would be
imposing a greater restriction that what the standard currently says
(which is convertible to bool).
</p>
<hr>
<a name="290"><h3>290.&nbsp;Requirements to for_each and its function object</h3></a><p>
<b>Section:</b>&nbsp;25.1.1 <a href="lib-algorithms.html#lib.alg.foreach"> [lib.alg.foreach]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Angelika Langer&nbsp; <b>Date:</b>&nbsp;03 Jan 2001</p>
<p>The specification of the for_each algorithm does not have a
&quot;Requires&quot; section, which means that there are no
restrictions imposed on the function object whatsoever. In essence it
means that I can provide any function object with arbitrary side
effects and I can still expect a predictable result. In particular I
can expect that the function object is applied exactly last - first
times, which is promised in the &quot;Complexity&quot; section.
</p>

<p>I don't see how any implementation can give such a guarantee
without imposing requirements on the function object.
</p>

<p>Just as an example: consider a function object that removes
elements from the input sequence.  In that case, what does the
complexity guarantee (applies f exactly last - first times) mean?
</p>

<p>One can argue that this is obviously a nonsensical application and
a theoretical case, which unfortunately it isn't.  I have seen
programmers shooting themselves in the foot this way, and they did not
understand that there are restrictions even if the description of the
algorithm does not say so.
</p>
<p><b>Proposed resolution:</b></p>
<p>Add a &quot;Requires&quot; section to section 25.1.1 similar to those
proposed for transform and the numeric algorithms (see issue
<a href="lwg-defects.html#242">242</a>):
</p>

<blockquote>
    -2- <b>Requires</b>: In the range [first, last], f shall not invalidate
    iterators or subranges.
</blockquote>

<p><i>[Copenhagen: The LWG agrees that a function object passed to an
algorithm should not invalidate iterators in the range that the
algorithm is operating on.  The LWG believes that this should be a
blanket statement in Clause 25, not just a special requirement for
<tt>for_each</tt>.
]</i></p>

<hr>
<a name="291"><h3>291.&nbsp;Underspecification of set algorithms</h3></a><p>
<b>Section:</b>&nbsp;25.3.5 <a href="lib-algorithms.html#lib.alg.set.operations"> [lib.alg.set.operations]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Review">Review</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;03 Jan 2001</p>
<p>
The standard library contains four algorithms that compute set
operations on sorted ranges: <tt>set_union</tt>, <tt>set_intersection</tt>,
<tt>set_difference</tt>, and <tt>set_symmetric_difference</tt>.  Each
of these algorithms takes two sorted ranges as inputs, and writes the
output of the appropriate set operation to an output range.  The elements
in the output range are sorted.
</p>

<p>
The ordinary mathematical definitions are generalized so that they
apply to ranges containing multiple copies of a given element.  Two
elements are considered to be &quot;the same&quot; if, according to an
ordering relation provided by the user, neither one is less than the
other.  So, for example, if one input range contains five copies of an
element and another contains three, the output range of <tt>set_union</tt>
will contain five copies, the output range of
<tt>set_intersection</tt> will contain three, the output range of
<tt>set_difference</tt> will contain two, and the output range of
<tt>set_symmetric_difference</tt> will contain two.
</p>

<p>
Because two elements can be &quot;the same&quot; for the purposes
of these set algorithms, without being identical in other respects
(consider, for example, strings under case-insensitive comparison),
this raises a number of unanswered questions:
</p>

<ul>
<li>If we're copying an element that's present in both of the
input ranges, which one do we copy it from?</li>
<li>If there are <i>n</i> copies of an element in the relevant
input range, and the output range will contain fewer copies (say
<i>m</i>) which ones do we choose?  The first <i>m</i>, or the last
<i>m</i>, or something else?</li>
<li>Are these operations stable?  That is, does a run of equivalent
elements appear in the output range in the same order as as it
appeared in the input range(s)?</li>
</ul>

<p>
The standard should either answer these questions, or explicitly
say that the answers are unspecified.  I prefer the former option,
since, as far as I know, all existing implementations behave the
same way.
</p>

<p><b>Proposed resolution:</b></p>

<p>Add the following to the end of 25.3.5.2 <a href="lib-algorithms.html#lib.set.union"> [lib.set.union]</a> paragraph 5:</p>
<blockquote>
If [first1, last1) contains <i>m</i> elements that are equivalent to
each other and [first2, last2) contains <i>n</i> elements that are
equivalent to them, then max(<i>m</i>, <i>n</i>) of these elements
will be copied to the output range: all <i>m</i> of these elements
from [first1, last1), and the last max(<i>n-m</i>, 0) of them from
[first2, last2), in that order.
</blockquote>

<p>Add the following to the end of 25.3.5.3 <a href="lib-algorithms.html#lib.set.intersection"> [lib.set.intersection]</a> paragraph 5:</p>
<blockquote>
If [first1, last1) contains <i>m</i> elements that are equivalent to each
other and [first2, last2) contains <i>n</i> elements that are
equivalent to them, the first min(<i>m</i>, <i>n</i>) of those 
elements from [first1, last1) are copied to the output range.
</blockquote>

<p>Add a new paragraph, <b>Notes</b>, after 25.3.5.4 <a href="lib-algorithms.html#lib.set.difference"> [lib.set.difference]</a>
paragraph 4:</p>
<blockquote>
If [first1, last1) contains <i>m</i> elements that are equivalent to each
other and [first2, last2) contains <i>n</i> elements that are
equivalent to them, the last max(<i>m-n</i>, 0) elements from 
[first1, last1) are copied to the output range.
</blockquote>

<p>Add a new paragraph, <b>Notes</b>, after 25.3.5.5 <a href="lib-algorithms.html#lib.set.symmetric.difference"> [lib.set.symmetric.difference]</a>
paragraph 4:</p>
<blockquote>
If [first1, last1) contains <i>m</i> elements that are equivalent to
each other and [first2, last2) contains <i>n</i> elements that are
equivalent to them, then |<i>m - n</i>| of those elements will be
copied to the output range: the last <i>m - n</i> of these elements
from [first1, last1) if <i>m</i> &gt; <i>n</i>, and the last <i>n -
m</i> of these elements from [first2, last2) if <i>m</i> &lt; <i>n</i>.
</blockquote>

<p><i>[Santa Cruz: it's believed that this language is clearer than
  what's in the Standard.  However, it's also believed that the
  Standard may already make these guarantees (although not quite in
  these words).  Bill and Howard will check and see whether they think
  that some or all of these changes may be redundant.  If so, we may
  close this issue as NAD.]</i></p>

<p><b>Rationale:</b></p>
<p>For simple cases, these descriptions are equivalent to what's
  already in the Standard.  For more complicated cases, they describe
  the behavior of existing implementations.</p>
<hr>
<a name="294"><h3>294.&nbsp;User defined macros and standard headers</h3></a><p>
<b>Section:</b>&nbsp;17.4.3.1.1 <a href="lib-intro.html#lib.macro.names"> [lib.macro.names]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;James Kanze&nbsp; <b>Date:</b>&nbsp;11 Jan 2001</p>
<p>Paragraph 2 of 17.4.3.1.1 <a href="lib-intro.html#lib.macro.names"> [lib.macro.names]</a> reads: &quot;A
translation unit that includes a header shall not contain any macros
that define names declared in that header.&quot; As I read this, it
would mean that the following program is legal:</p>

<pre>
  #define npos 3.14
  #include &lt;sstream&gt;
</pre>

<p>since npos is not defined in &lt;sstream&gt;.  It is, however, defined
in &lt;string&gt;, and it is hard to imagine an implementation in
which &lt;sstream&gt; didn't include &lt;string&gt;.</p>

<p>I think that this phrase was probably formulated before it was
decided that a standard header may freely include other standard
headers.  The phrase would be perfectly appropriate for C, for
example.  In light of 17.4.4.1 <a href="lib-intro.html#lib.res.on.headers"> [lib.res.on.headers]</a> paragraph 1, however,
it isn't stringent enough.</p>
<p><b>Proposed resolution:</b></p>
<p>In paragraph 2 of 17.4.3.1.1 <a href="lib-intro.html#lib.macro.names"> [lib.macro.names]</a>, change &quot;A
translation unit that includes a header shall not contain any macros
that define names declared in that header.&quot; to &quot;A
translation unit that includes a header shall not contain any macros
that define names declared in any standard header.&quot;</p>

<p><i>[Copenhagen: the general idea is clearly correct, but there is
concern about making sure that the two paragraphs in 17.4.3.1.1 <a href="lib-intro.html#lib.macro.names"> [lib.macro.names]</a> remain consistent.  Nathan will provide new 
wording.]</i></p>

<hr>
<a name="299"><h3>299.&nbsp;Incorrect return types for iterator dereference</h3></a><p>
<b>Section:</b>&nbsp;24.1.4 <a href="lib-iterators.html#lib.bidirectional.iterators"> [lib.bidirectional.iterators]</a>, 24.1.5 <a href="lib-iterators.html#lib.random.access.iterators"> [lib.random.access.iterators]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;John Potter&nbsp; <b>Date:</b>&nbsp;22 Jan 2001</p>
<p>
In section 24.1.4 <a href="lib-iterators.html#lib.bidirectional.iterators"> [lib.bidirectional.iterators]</a>,
Table 75 gives the return type of *r-- as convertible to T.  This is
not consistent with Table 74 which gives the return type of *r++ as
T&amp;.  *r++ = t is valid while *r-- = t is invalid.
</p>

<p>
In section 24.1.5 <a href="lib-iterators.html#lib.random.access.iterators"> [lib.random.access.iterators]</a>,
Table 76 gives the return type of a[n] as convertible to T.  This is
not consistent with the semantics of *(a + n) which returns T&amp; by
Table 74.  *(a + n) = t is valid while a[n] = t is invalid.
</p>

<p>
Discussion from the Copenhagen meeting: the first part is
uncontroversial.  The second part, operator[] for Random Access
Iterators, requires more thought.  There are reasonable arguments on
both sides.  Return by value from operator[] enables some potentially
useful iterators, e.g. a random access &quot;iota iterator&quot; (a.k.a
&quot;counting iterator&quot; or &quot;int iterator&quot;).  There isn't any obvious way
to do this with return-by-reference, since the reference would be to a
temporary.  On the other hand, <tt>reverse_iterator</tt> takes an
arbitrary Random Access Iterator as template argument, and its
operator[] returns by reference.  If we decided that the return type
in Table 76 was correct, we would have to change
<tt>reverse_iterator</tt>.  This change would probably affect user
code.
</p>

<p>
History: the contradiction between <tt>reverse_iterator</tt> and the
Random Access Iterator requirements has been present from an early
stage.  In both the STL proposal adopted by the committee
(N0527==94-0140) and the STL technical report (HPL-95-11 (R.1), by
Stepanov and Lee), the Random Access Iterator requirements say that
operator[]'s return value is &quot;convertible to T&quot;.  In N0527
reverse_iterator's operator[] returns by value, but in HPL-95-11
(R.1), and in the STL implementation that HP released to the public,
reverse_iterator's operator[] returns by reference.  In 1995, the
standard was amended to reflect the contents of HPL-95-11 (R.1).  The
original intent for operator[] is unclear.
</p>

<p>
In the long term it may be desirable to add more fine-grained 
iterator requirements, so that access method and traversal strategy
can be decoupled.  (See &quot;Improved Iterator Categories and
Requirements&quot;, N1297 = 01-0011, by Jeremy Siek.)  Any decisions
about issue 299 should keep this possibility in mind.
</p>

<p><b>Proposed resolution:</b></p>
<p>In section 24.1.4 <a href="lib-iterators.html#lib.bidirectional.iterators"> [lib.bidirectional.iterators]</a>, change the return type in table
75 from &quot;convertible to T&quot; to T&amp;.</p>

<p>In section 24.1.5 <a href="lib-iterators.html#lib.random.access.iterators"> [lib.random.access.iterators]</a>, change the return type in table
76 from &quot;convertible to T&quot; to T&amp;.</p>

<p><i>[Cura&ccedil;ao: Jeremy volunteered to work on this issue.]</i></p>

<p><b>Rationale:</b></p>
<p>This proposed resolution is a compromise between John Potter's
resolution, which requires <tt>T&amp;</tt> as the return type of
<tt>a[n]</tt>, and the current wording, which requires convertible to
<tt>T</tt>. The compromise is to keep the convertible to <tt>T</tt>
for the return type of the expression <tt>a[n]</tt>, but to also add
<tt>a[n] = t</tt> as a valid expression. This compromise &quot;saves&quot; the
common case uses of random access iterators, while at the same time
allowing iterators such as counting iterator and caching file
iterators to remain random access iterators (iterators where the
lifetime of the object returned by <tt>operator*()</tt> is tied to the
lifetime of the iterator).
</p>

<p>
Note there is one kind of mutable random access iterator that
will no longer meet the new requirements. Currently, iterators that
return an r-value from <tt>operator[]</tt> meet the requirements for a
mutable random access iterartor, even though the expression <tt>a[n] =
t</tt> will only modify a temporary that goes away. With this proposed
resolution, <tt>a[n] = t</tt> will be required to have the same
operational semantics as <tt>*(a + n) = t</tt>.
</p>

<p>Note also that <tt>reverse_iterator</tt> (24.4.1 <a href="lib-iterators.html#lib.reverse.iterators"> [lib.reverse.iterators]</a>)
  may be broken.  However, this proposed resolution doesn't break it
  any worse than it already is.  This is a separate issue.  (Issue
  <a href="lwg-active.html#386">386</a>.)</p>
<hr>
<a name="309"><h3>309.&nbsp;Does sentry catch exceptions?</h3></a><p>
<b>Section:</b>&nbsp;27.6 <a href="lib-iostreams.html#lib.iostream.format"> [lib.iostream.format]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Review">Review</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;19 Mar 2001</p>
<p>
The descriptions of the constructors of basic_istream&lt;&gt;::sentry
(27.6.1.1.2 <a href="lib-iostreams.html#lib.istream::sentry"> [lib.istream::sentry]</a>) and basic_ostream&lt;&gt;::sentry
(27.6.2.3 <a href="lib-iostreams.html#lib.ostream::sentry"> [lib.ostream::sentry]</a>) do not explain what the functions do in
case an exception is thrown while they execute. Some current
implementations allow all exceptions to propagate, others catch them
and set ios_base::badbit instead, still others catch some but let
others propagate.
</p>

<p>
The text also mentions that the functions may call setstate(failbit)
(without actually saying on what object, but presumably the stream
argument is meant).  That may have been fine for
basic_istream&lt;&gt;::sentry prior to issue <a href="lwg-defects.html#195">195</a>, since
the function performs an input operation which may fail. However,
issue <a href="lwg-defects.html#195">195</a> amends 27.6.1.1.2 <a href="lib-iostreams.html#lib.istream::sentry"> [lib.istream::sentry]</a>, p2 to
clarify that the function should actually call setstate(failbit |
eofbit), so the sentence in p3 is redundant or even somewhat
contradictory.
</p>

<p>
The same sentence that appears in 27.6.2.3 <a href="lib-iostreams.html#lib.ostream::sentry"> [lib.ostream::sentry]</a>, p3
doesn't seem to be very meaningful for basic_istream&lt;&gt;::sentry
which performs no input. It is actually rather misleading since it
would appear to guide library implementers to calling
setstate(failbit) when os.tie()-&gt;flush(), the only called function,
throws an exception (typically, it's badbit that's set in response to
such an event).
</p>
<p><b>Proposed resolution:</b></p>
<p>Remove the last sentence of 27.6.1.1.2 <a href="lib-iostreams.html#lib.istream::sentry"> [lib.istream::sentry]</a> p5 (but not
  the footnote, which should be moved to the preceding sentence).</p>
<p>Remove the last sentence of 27.6.2.3 <a href="lib-iostreams.html#lib.ostream::sentry"> [lib.ostream::sentry]</a> p3 (but not
  the footnote, which should be moved to the preceding sentence).</p>
<p><b>Rationale:</b></p>
<p>The LWG feels that no clarification of EH policy is necessary: the
  standard is precise about which operations sentry's constructor
  performs, and about which of those operations can throw.  However, the
  sentence at the end should be removed because it's redundant.</p>
<hr>
<a name="342"><h3>342.&nbsp;seek and eofbit</h3></a><p>
<b>Section:</b>&nbsp;27.6.1.3 <a href="lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Howard Hinnant&nbsp; <b>Date:</b>&nbsp;09 Oct 201</p>
<p>I think we have a defect.</p>

<p>According to lwg issue <a href="lwg-defects.html#60">60</a> which is now a dr, the
description of seekg in 27.6.1.3 <a href="lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a> paragraph 38 now looks
like:</p>

<blockquote>
Behaves as an unformatted input function (as described in 27.6.1.3, 
paragraph 1), except that it does not count the number of characters 
extracted and does not affect the value returned by subsequent calls to 
gcount(). After constructing a sentry object, if fail() != true, 
executes rdbuf()&shy;&gt;pubseekpos( pos).
</blockquote>

<p>And according to lwg issue <a href="lwg-defects.html#243">243</a> which is also now a dr,
27.6.1.3, paragraph 1 looks like:</p>

<blockquote>
Each unformatted input function begins execution by constructing an 
object of class sentry with the default argument noskipws (second) 
argument true. If the sentry object returns true, when converted to a 
value of type bool, the function endeavors to obtain the requested 
input.  Otherwise, if the sentry constructor exits by throwing an 
exception or if the sentry object returns false, when converted to a 
value of type bool, the function returns without attempting to obtain 
any input. In either case the number of extracted characters is set to 
0; unformatted input functions taking a character array of non-zero 
size as an argument shall also store a null character (using charT()) 
in the first location of the array. If an exception is thrown during 
input then ios::badbit is turned on in *this'ss error state. If 
(exception()&amp;badbit)!= 0 then the exception is rethrown. It also counts 
the number of characters extracted. If no exception has been thrown it 
ends by storing the count in a member object and returning the value 
specified. In any event the sentry object is destroyed before leaving 
the unformatted input function.
</blockquote>

<p>And finally 27.6.1.1.2/5 says this about sentry:</p>

<blockquote>
If, after any preparation is completed, is.good() is true, ok_ != false 
otherwise, ok_ == false.
</blockquote>

<p>
So although the seekg paragraph says that the operation proceeds if 
!fail(), the behavior of unformatted functions says the operation 
proceeds only if good().  The two statements are contradictory when only 
eofbit is set.  I don't think the current text is clear which condition 
should be respected.
</p>

<p><b>Further discussion from Redmond:</b></p>

<p>PJP: It doesn't seem quite right to say that <tt>seekg</tt> is
&quot;unformatted&quot;. That makes specific claims about sentry that
aren't quite appropriate for seeking, which has less fragile failure
modes than actual input.  If we do really mean that it's unformatted
input, it should behave the same way as other unformatted input.  On
the other hand, &quot;principle of least surprise&quot; is that seeking from EOF
ought to be OK.</p>

<p>Dietmar: nothing should depend on eofbit.  Eofbit should only be
examined by the user to determine why something failed.</p>

<p><i>[Taken from c++std-lib-8873, c++std-lib-8874, c++std-lib-8876]</i></p>

<p><b>Proposed resolution:</b></p>

<p><i>[Santa Cruz: On the one hand, it would clearly be silly to seek
  to a non-EOF position without resetting eofbit.  On the other hand,
  having seek clear eofbit explicitly would set a major precedent:
  there is currently <i>no</i> place where any of the flags are reset
  without the user explicitly asking for them to be.  This is the tip
  of a general problem, that the various flags are stickier than many
  users might expect.  Bill, Gaby, and Howard will discuss this issue
  and propose a resolution.]</i></p>

<hr>
<a name="347"><h3>347.&nbsp;locale::category and bitmask requirements</h3></a><p>
<b>Section:</b>&nbsp;22.1.1.1.1 <a href="lib-locales.html#lib.locale.category"> [lib.locale.category]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Review">Review</a>&nbsp; <b>Submitter:</b>&nbsp;P.J. Plauger, Nathan Myers&nbsp; <b>Date:</b>&nbsp;23 Oct 2001</p>
<p>
In 22.1.1.1.1 <a href="lib-locales.html#lib.locale.category"> [lib.locale.category]</a> paragraph 1, the category members
are described as bitmask elements.  In fact, the bitmask requirements
in 17.3.2.1.2 <a href="lib-intro.html#lib.bitmask.types"> [lib.bitmask.types]</a> don't seem quite right: <tt>none</tt>
and <tt>all</tt> are bitmask constants, not bitmask elements.</p>

<p>In particular, the requirements for <tt>none</tt> interact poorly
with the requirement that the LC_* constants from the C library must
be recognizable as C++ locale category constants.  LC_* values should
not be mixed with these values to make category values.</p>

<p>We have two options for the proposed resolution.  Informally:
option 1 removes the requirement that LC_* values be recognized as
category arguments.  Option 2 changes the category type so that this
requirement is implementable, by allowing <tt>none</tt> to be some
value such as 0x1000 instead of 0.</p>

<p>Nathan writes: &quot;I believe my proposed resolution [Option 2] merely
re-expresses the status quo more clearly, without introducing any
changes beyond resolving the DR.</p>

<p><b>Proposed resolution:</b></p>
<p>Replace the first two paragraphs of 22.1.1.1 <a href="lib-locales.html#lib.locale.types"> [lib.locale.types]</a> with:</p>
<blockquote>
<pre>
    typedef int category;
</pre>

<p>Valid category values include the <tt>locale</tt> member bitmask
elements <tt>collate</tt>, <tt>ctype</tt>, <tt>monetary</tt>,
<tt>numeric</tt>, <tt>time</tt>, and <tt>messages</tt>, each of which
represents a single locale category. In addition, <tt>locale</tt> member
bitmask constant <tt>none</tt> is defined as zero and represents no
category. And locale member bitmask constant <tt>all</tt> is defined such that
the expression</p>
<pre>
    (collate | ctype | monetary | numeric | time | messages | all) == all
</pre>
<p>
is <tt>true</tt>, and represents the union of all categories.  Further
the expression <tt>(X | Y)</tt>, where <tt>X</tt> and <tt>Y</tt> each
represent a single category, represents the union of the two
categories.
</p>

<p>
<tt>locale</tt> member functions expecting a <tt>category</tt>
argument require one of the <tt>category</tt> values defined above, or
the union of two or more such values. Such a <tt>category</tt>
argument identifies a set of locale categories. Each locale category,
in turn, identifies a set of locale facets, including at least those
shown in Table 51:
</p>
</blockquote>
<p><i>[Cura&ccedil;ao: need input from locale experts.]</i></p>

<p><b>Rationale:</b></p>

<p>The LWG considered, and rejected, an alternate proposal (described
  as &quot;Option 2&quot; in the discussion).  The main reason for rejecting it
  was that library implementors were concerened about implementation
  difficult, given that getting a C++ library to work smoothly with a
  separately written C library is already a delicate business.  Some
  library implementers were also concerned about the issue of adding
  extra locale categories.</p>

<blockquote>
<p>
<b>Option 2:</b> <br>
Replace the first paragraph of 22.1.1.1 <a href="lib-locales.html#lib.locale.types"> [lib.locale.types]</a> with:</p>
<blockquote>
<p>
Valid category values include the enumerated values.  In addition, the
result of applying commutative operators | and &amp; to any two valid 
values is valid, and results in the setwise union and intersection, 
respectively, of the argument categories.  The values <tt>all</tt> and 
<tt>none</tt> are defined such that for any valid value <tt>cat</tt>, the
expressions <tt>(cat | all == all)</tt>, <tt>(cat &amp; all == cat)</tt>,
<tt>(cat | none == cat)</tt> and <tt>(cat &amp; none == none)</tt> are 
true.  For non-equal values <tt>cat1</tt> and <tt>cat2</tt> of the
remaining enumerated values, <tt>(cat1 &amp; cat2 == none)</tt> is true.
For any valid categories <tt>cat1</tt> and <tt>cat2</tt>, the result
of <tt>(cat1 &amp; ~cat2)</tt> is valid, and equals the setwise union of 
those categories found in <tt>cat1</tt> but not found in <tt>cat2</tt>.
[Footnote: it is not required that <tt>all</tt> equal the setwise union
of the other enumerated values; implementations may add extra categories.]
</p>
</blockquote>
</blockquote>
<hr>
<a name="352"><h3>352.&nbsp;missing fpos requirements</h3></a><p>
<b>Section:</b>&nbsp;21.1.2 <a href="lib-strings.html#lib.char.traits.typedefs"> [lib.char.traits.typedefs]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Review">Review</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;2 Dec 2001</p>
<p>
<i>(1)</i>
There are no requirements on the <tt>stateT</tt> template parameter of
<tt>fpos</tt> listed in 27.4.3. The interface appears to require that
the type be at least Assignable and CopyConstructible (27.4.3.1, p1),
and I think also DefaultConstructible (to implement the operations in
Table 88).
</p>
<p>
21.1.2, p3, however, only requires that
<tt>char_traits&lt;charT&gt;::state_type</tt> meet the requirements of
CopyConstructible types.
</p>
<p>
<i>(2)</i>
Additionally, the <tt>stateT</tt> template argument has no
corresponding typedef in fpos which might make it difficult to use in
generic code.
</p>
<p><b>Proposed resolution:</b></p>
<p>
Modify 21.1.2, p4 from
</p>
<p>
    Requires: <tt>state_type</tt> shall meet the requirements of
              CopyConstructible types (20.1.3).
</p>
<p>
    Requires: state_type shall meet the requirements of Assignable
              (23.1, p4), CopyConstructible (20.1.3), and
              DefaultConstructible  (20.1.4) types.
</p>

<p><b>Rationale:</b></p>
<p>The LWG feels this is two issues, as indicated above. The first is
a defect---std::basic_fstream is unimplementable without these
additional requirements---and the proposed resolution fixes it.  The
second is questionable; who would use that typedef?  The class
template fpos is used only in a very few places, all of which know the
state type already.  Unless motivation is provided, the second should
be considered NAD.</p>
<hr>
<a name="355"><h3>355.&nbsp;Operational semantics for a.back()</h3></a><p>
<b>Section:</b>&nbsp;23.1.1 <a href="lib-containers.html#lib.sequence.reqmts"> [lib.sequence.reqmts]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Review">Review</a>&nbsp; <b>Submitter:</b>&nbsp;Yaroslav Mironov&nbsp; <b>Date:</b>&nbsp;23 Jan 2002</p>

<p>Table 68 &quot;Optional Sequence Operations&quot; in 23.1.1/12
specifies operational semantics for &quot;a.back()&quot; as
&quot;*--a.end()&quot;, which may be ill-formed <i>[because calling
operator-- on a temporary (the return) of a built-in type is
ill-formed]</i>, provided a.end() returns a simple pointer rvalue
(this is almost always the case for std::vector::end(), for
example). Thus, the specification is not only incorrect, it
demonstrates a dangerous construct: &quot;--a.end()&quot; may
successfully compile and run as intended, but after changing the type
of the container or the mode of compilation it may produce
compile-time error. </p>

<p><b>Proposed resolution:</b></p>
<p>Change the specification in table 68 &quot;Optional Sequence
Operations&quot; in 23.1.1/12 for &quot;a.back()&quot; from</p>


<blockquote>
*--a.end()
</blockquote>

<p>to</p>

<blockquote>
  { iterator tmp = a.end(); --tmp; *tmp; }
</blockquote>

<p>and the specification for &quot;a.pop_back()&quot; from</p>

<blockquote>
a.erase(--a.end())
</blockquote>

<p>to</p>

<blockquote>
  { iterator tmp = a.end(); --tmp; a.erase(tmp); }
</blockquote>

<p><i>[Cura&ccedil;ao: LWG changed PR from &quot;{ X::iterator tmp =
a.end(); return *--tmp; }&quot; to &quot;*a.rbegin()&quot;, and from
&quot;{ X::iterator tmp = a.end(); a.erase(--tmp); }&quot; to
&quot;a.erase(rbegin())&quot;.]</i></p>

<p><i>[There is a second possible defect; table 68 &quot;Optional
Sequence Operations&quot; in the &quot;Operational Semantics&quot;
column uses operations present only in the &quot;Reversible
Container&quot; requirements, yet there is no stated dependency
between these separate requirements tables. Ask in Santa Cruz if the
LWG would like a new issue opened.]</i></p>

<p><i>[Santa Cruz: the proposed resolution is even worse than what's in
  the current standard: erase is undefined for reverse iterator.  If
  we're going to make the change, we need to define a temporary and
  use operator--.  Additionally, we don't know how prevalent this is:
  do we need to make this change in more than one place?  Martin has
  volunteered to review the standard and see if this problem occurs
  elsewhere.]</i></p>

<p><i>[Oxford: Matt provided new wording to address the concerns raised
  in Santa Cruz.  It does not appear that this problem appears
  anywhere else in clauses 23 or 24.]</i></p>

<hr>
<a name="356"><h3>356.&nbsp;Meaning of ctype_base::mask enumerators</h3></a><p>
<b>Section:</b>&nbsp;22.2.1 <a href="lib-locales.html#lib.category.ctype"> [lib.category.ctype]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;23 Jan 2002</p>

<p>What should the following program print?</p>

<pre>
  #include &lt;locale&gt;
  #include &lt;iostream&gt;

  class my_ctype : public std::ctype&lt;char&gt;
  {
    typedef std::ctype&lt;char&gt; base;
  public:
    my_ctype(std::size_t refs = 0) : base(my_table, false, refs)
    {
      std::copy(base::classic_table(), base::classic_table() + base::table_size,
                my_table);
      my_table[(unsigned char) '_'] = (base::mask) (base::print | base::space);
    }
  private:
    mask my_table[base::table_size];
  };

  int main()
  {
    my_ctype ct;
    std::cout &lt;&lt; &quot;isspace: &quot; &lt;&lt; ct.is(std::ctype_base::space, '_') &lt;&lt; &quot;    &quot;
              &lt;&lt; &quot;isalpha: &quot; &lt;&lt; ct.is(std::ctype_base::alpha, '_') &lt;&lt; std::endl;
  }
</pre>

<p>The goal is to create a facet where '_' is treated as whitespace.</p>

<p>On gcc 3.0, this program prints &quot;isspace: 1 isalpha: 0&quot;.  On
Microsoft C++ it prints &quot;isspace: 1 isalpha: 1&quot;.</p>

<p>
I believe that both implementations are legal, and the standard does not
give enough guidance for users to be able to use std::ctype's
protected interface portably.</p>

<p>
The above program assumes that ctype_base::mask enumerators like
<tt>space</tt> and <tt>print</tt> are disjoint, and that the way to
say that a character is both a space and a printing character is to or
those two enumerators together.  This is suggested by the &quot;exposition
only&quot; values in 22.2.1 <a href="lib-locales.html#lib.category.ctype"> [lib.category.ctype]</a>, but it is nowhere specified in
normative text.  An alternative interpretation is that the more
specific categories subsume the less specific.  The above program
gives the results it does on the Microsoft compiler because, on that
compiler, <tt>print</tt> has all the bits set for each specific
printing character class.
</p>

<p>From the point of view of std::ctype's public interface, there's no
important difference between these two techniques.  From the point of
view of the protected interface, there is.  If I'm defining a facet
that inherits from std::ctype&lt;char&gt;, I'm the one who defines the
value that table()['a'] returns.  I need to know what combination of
mask values I should use.  This isn't so very esoteric: it's exactly
why std::ctype has a protected interface.  If we care about users
being able to write their own ctype facets, we have to give them a
portable way to do it.
</p>

<p>
Related reflector messages:
lib-9224, lib-9226, lib-9229, lib-9270, lib-9272, lib-9273, lib-9274,
lib-9277, lib-9279.
</p>

<p>Issue <a href="lwg-defects.html#339">339</a> is related, but not identical.  The
proposed resolution if issue <a href="lwg-defects.html#339">339</a> says that
ctype_base::mask must be a bitmask type. It does not say that the
ctype_base::mask elements are bitmask elements, so it doesn't
directly affect this issue.</p>

<p>More comments from Benjamin Kosnik, who believes that 
that C99 compatibility essentially requires what we're
calling option 1 below.</p>

<blockquote>
<pre>
I think the C99 standard is clear, that isspace -&gt; !isalpha.
--------

#include &lt;locale&gt;
#include &lt;iostream&gt;

class my_ctype : public std::ctype&lt;char&gt;
{
private:
  typedef std::ctype&lt;char&gt; base;
  mask my_table[base::table_size];

public:
  my_ctype(std::size_t refs = 0) : base(my_table, false, refs)
  {
    std::copy(base::classic_table(), base::classic_table() + base::table_size,
              my_table);
    mask both = base::print | base::space;
    my_table[static_cast&lt;mask&gt;('_')] = both;
  }
};

int main()
{
  using namespace std;
  my_ctype ct;
  cout &lt;&lt; &quot;isspace: &quot; &lt;&lt; ct.is(ctype_base::space, '_') &lt;&lt; endl;
  cout &lt;&lt; &quot;isprint: &quot; &lt;&lt; ct.is(ctype_base::print, '_') &lt;&lt; endl;

  // ISO C99, isalpha iff upper | lower set, and !space.
  // 7.5, p 193
  // -&gt; looks like g++ behavior is correct.
  // 356 -&gt; bitmask elements are required for ctype_base
  // 339 -&gt; bitmask type required for mask
  cout &lt;&lt; &quot;isalpha: &quot; &lt;&lt; ct.is(ctype_base::alpha, '_') &lt;&lt; endl;
}
</pre>
</blockquote>

<p><b>Proposed resolution:</b></p>
<p>Informally, we have three choices:</p> 
<ol>
<li>Require that the enumerators are disjoint (except for alnum and
graph)</li>
<li>Require that the enumerators are not disjoint, and specify which
of them subsume which others.  (e.g. mandate that lower includes alpha
and print)</li>
<li>Explicitly leave this unspecified, which the result that the above
program is not portable.</li>
</ol>

<p>Either of the first two options is just as good from the standpoint
of portability.  Either one will require some implementations to
change.</p>

<p><i>[
More discussion is needed.  Nobody likes option 3.  Options 1 and 2
are both controversial, 2 perhaps less so.  Benjamin thinks that
option 1 is required for C99 compatibility.
]</i></p>

<hr>
<a name="359"><h3>359.&nbsp;num_put&lt;&gt;::do_put (..., bool) undocumented</h3></a><p>
<b>Section:</b>&nbsp;22.2.2.2.1 <a href="lib-locales.html#lib.facet.num.put.members"> [lib.facet.num.put.members]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Review">Review</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;12 Mar 2002</p>
<p>22.2.2.2.1, p1:</p>

    <pre>
    iter_type put (iter_type out, ios_base&amp; str, char_type fill,
                   bool val) const;
    ...

    1   Returns: do_put (out, str, fill, val).
    </pre>

<p>AFAICS, the behavior of do_put (..., bool) is not documented anywhere,
however, 22.2.2.2.2, p23:</p>

<blockquote>
<pre>
iter_type put (iter_type out, ios_base&amp; str, char_type fill,
               bool val) const;
</pre>


        Effects: If (str.flags() &amp; ios_base::boolalpha) == 0 then do
             out = do_put(out, str, fill, (int)val)
           Otherwise do
<pre>
             string_type s =
                 val ? use_facet&lt;ctype&lt;charT&gt; &gt;(loc).truename()
                     : use_facet&lt;ctype&lt;charT&gt; &gt;(loc).falsename();
</pre>
           and then insert the characters of s into out. <i>out</i>.
</blockquote>

<p>
This means that the bool overload of <tt>do_put()</tt> will never be called,
which contradicts the first paragraph. Perhaps the declaration
should read <tt>do_put()</tt>, and not <tt>put()</tt>?
</p>

<p>
Note also that there is no <b>Returns</b> clause for this function, which
should probably be corrected, just as should the second occurrence
of <i>&quot;out.&quot;</i> in the text.
</p>

<p>
I think the least invasive change to fix it would be something like
the following:
</p>
<p><b>Proposed resolution:</b></p>
<p>In 22.2.2.2.2 <a href="lib-locales.html#lib.facet.num.put.virtuals"> [lib.facet.num.put.virtuals]</a>, just above paragraph 1, remove
  the <tt>bool</tt> overload.</p>

<p>
In 22.2.2.2.2 <a href="lib-locales.html#lib.facet.num.put.virtuals"> [lib.facet.num.put.virtuals]</a>, p23, make the following changes
</p>

<blockquote>
     Replace <tt>put()</tt> with <tt>do_put()</tt> in the declaration
     of the member function.
</blockquote>

<blockquote>
    Change the <b>Effects</b> clause to a <b>Returns</b> clause (to
    avoid the requirement to call <tt>do_put(..., int)</tt> from <tt>
    do_put (..., bool))</tt>
    like so:
</blockquote>

<blockquote>
    23   <b>Returns</b>: If <tt>(str.flags() &amp;
         ios_base::boolalpha) == 0</tt> then
         <tt>do_put (out, str, fill, (long)val)</tt>
         Otherwise the function obtains a string <tt>s</tt> as if by
<pre>
             string_type s =
                val ? use_facet&lt;ctype&lt;charT&gt; &gt;(loc).truename()
                    : use_facet&lt;ctype&lt;charT&gt; &gt;(loc).falsename();
</pre>
         and then inserts each character <tt>c</tt> of s into out via
           <tt>*out++ = c</tt>
         and returns <tt>out</tt>.
</blockquote>

<p><b>Rationale:</b></p>
<p>
This fixes a couple of obvious typos, and also fixes what appears to
be a requirement of gratuitous inefficiency.
</p>
<hr>
<a name="362"><h3>362.&nbsp;bind1st/bind2nd type safety</h3></a><p>
<b>Section:</b>&nbsp;20.3.6.2 <a href="lib-utilities.html#lib.bind.1st"> [lib.bind.1st]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Andrew Demkin&nbsp; <b>Date:</b>&nbsp;26 Apr 2002</p>
<p>
The definition of bind1st() (20.3.6.2 <a href="lib-utilities.html#lib.bind.1st"> [lib.bind.1st]</a>) can result in
the construction of an unsafe binding between incompatible pointer
types. For example, given a function whose first parameter type is
'pointer to T', it's possible without error to bind an argument of
type 'pointer to U' when U does not derive from T:
</p>
<pre>
   foo(T*, int);

   struct T {};
   struct U {};

   U u;

   int* p;
   int* q;

   for_each(p, q, bind1st(ptr_fun(foo), &amp;u));    // unsafe binding
</pre>

<p>
The definition of bind1st() includes a functional-style conversion to
map its argument to the expected argument type of the bound function
(see below):
</p>
<pre>
  typename Operation::first_argument_type(x)
</pre>

<p>
A functional-style conversion (5.2.3 <a href="expr.html#expr.type.conv"> [expr.type.conv]</a>) is defined to be
semantically equivalent to an explicit cast expression (5.4 <a href="expr.html#expr.cast"> [expr.cast]</a>), which may (according to 5.4, paragraph 5) be interpreted
as a reinterpret_cast, thus masking the error.
</p>

<p>The problem and proposed change also apply to 20.3.6.4 <a href="lib-utilities.html#lib.bind.2nd"> [lib.bind.2nd]</a>.</p>
<p><b>Proposed resolution:</b></p>
<p>
The simplest and most localized change to prevent such errors is to
require bind1st() use a static_cast expression rather than the
functional-style conversion; that is, have bind1st() return:
</p>
<pre>
   binder1st&lt;Operation&gt;( op,
     static_cast&lt;typename Operation::first_argument_type&gt;(x)).
</pre>

<p>
A more agressive solution is to change the semantics of
functional-style conversions to not permit a reinterpret_cast. For
contexts that require the semantics of reinterpret_cast, the language
may want to require the use of an explicit cast expression such as
'(T) x' or 'reinterpret_cast&lt;T&gt;(x)' and limit the behavior of
the functional notation to match statically-checked and standard
conversions (as defined by 5.2.9 and 4.10, etc.).  Although changing
the semantics of functional-style conversions may seem drastic and
does have language-wide ramifications, it has the benefit of better
unifying the conversion rules for user defined types and built-in
types, which can be especially important for generic template
programming.
</p>

<p><i>[Santa Cruz: it's clear that a function-style cast is
  wrong. Maybe a static cast would be better, or maybe no cast at
  all.  Jeremy will check with the original author of this part
  of the Standard and will see what the original intent was.]</i></p>
<hr>
<a name="365"><h3>365.&nbsp;Lack of const-qualification in clause 27</h3></a><p>
<b>Section:</b>&nbsp;27 <a href="lib-iostreams.html#lib.input.output"> [lib.input.output]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Review">Review</a>&nbsp; <b>Submitter:</b>&nbsp;Walter Brown, Marc Paterno&nbsp; <b>Date:</b>&nbsp;10 May 2002</p>
<p>
Some stream and streambuf member functions are declared non-const,
even thought they appear only to report information rather than to
change an object's logical state.  They should be declared const.  See
document N1360 for details and rationale.
</p>

<p>The list of member functions under discussion: <tt>in_avail</tt>,
<tt>showmanyc</tt>, <tt>tellg</tt>, <tt>tellp</tt>, <tt>is_open</tt>.</p>

<p>Related issue: <a href="lwg-closed.html#73">73</a>
</p>

<p><b>Proposed resolution:</b></p>
<p>In 27.8.1.5, 27.8.1.7, 27.8.1.8, 27.8.1.10, 27.8.1.11, and 27.8.1.13</p>
<p>Replace</p>
<pre>
  bool is_open();
</pre>
<p>with</p>
<pre>
  bool is_open() const;
</pre>
<p><b>Rationale:</b></p>
<p>Of the changes proposed in N1360, the only one that is safe is
changing the filestreams' is_open to const.  The LWG believed that
this was NAD the first time it considered this issue (issue <a href="lwg-closed.html#73">73</a>), but now thinks otherwise.  The corresponding streambuf
member function, after all,is already const.</p>

<p>The other proposed changes are less safe, because some streambuf
functions that appear merely to report a value do actually perform
mutating operations.  It's not even clear that they should be
considered &quot;logically const&quot;, because streambuf has two interfaces, a
public one and a protected one.  These functions may, and often do,
change the state as exposed by the protected interface, even if the
state exposed by the public interface is unchanged.</p>

<p>Note that implementers can make this change in a binary compatible
way by providing both overloads; this would be a conforming extension.</p>

<hr>
<a name="366"><h3>366.&nbsp;Excessive const-qualification</h3></a><p>
<b>Section:</b>&nbsp;27 <a href="lib-iostreams.html#lib.input.output"> [lib.input.output]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Walter Brown, Marc Paterno&nbsp; <b>Date:</b>&nbsp;10 May 2002</p>
<p>
The following member functions are declared const, yet return non-const
pointers. We believe they are should be changed, because they allow code
that may surprise the user. See document N1360 for details and
rationale.
</p>

<p><i>[Santa Cruz: the real issue is that we've got const member
functions that return pointers to non-const, and N1360 proposes
replacing them by overloaded pairs.  There isn't a consensus about
whether this is a real issue, since we've never said what our
constness policy is for iostreams.  N1360 relies on a distinction
between physical constness and logical constness; that distinction, or
those terms, does not appear in the standard.]</i></p>

<p><b>Proposed resolution:</b></p>
<p>In 27.4.4 and 27.4.4.2</p>
<p>Replace</p>
<pre>
  basic_ostream&lt;charT,traits&gt;* tie() const;
</pre>
<p>with</p>
<pre>
  basic_ostream&lt;charT,traits&gt;* tie();
  const basic_ostream&lt;charT,traits&gt;* tie() const;
</pre>

<p>and replace</p>
<pre>
  basic_streambuf&lt;charT,traits&gt;* rdbuf() const;
</pre>
<p>with</p>
<pre>
  basic_streambuf&lt;charT,traits&gt;* rdbuf();
  const basic_streambuf&lt;charT,traits&gt;* rdbuf() const;
</pre>

<p>In 27.5.2 and 27.5.2.3.1</p>
<p>Replace</p>
<pre>
  char_type* eback() const;
</pre>
<p>with</p>
<pre>
  char_type* eback();
  const char_type* eback() const;
</pre>

<p>Replace</p>
<pre>
  char_type gptr() const;
</pre>
<p>with</p>
<pre>
  char_type* gptr();
  const char_type* gptr() const;
</pre>

<p>Replace</p>
<pre>
  char_type* egptr() const;
</pre>
<p>with</p>
<pre>
  char_type* egptr();
  const char_type* egptr() const;
</pre>

<p>In 27.5.2 and 27.5.2.3.2</p>
<p>Replace</p>
<pre>
  char_type* pbase() const;
</pre>
<p>with</p>
<pre>
  char_type* pbase();
  const char_type* pbase() const;
</pre>

<p>Replace</p>
<pre>
  char_type* pptr() const;
</pre>
<p>with</p>
<pre>
  char_type* pptr();
  const char_type* pptr() const;
</pre>

<p>Replace</p>
<pre>
  char_type* epptr() const;
</pre>
<p>with</p>
<pre>
  char_type* epptr();
  const char_type* epptr() const;
</pre>

<p>In 27.7.2, 27.7.2.2, 27.7.3 27.7.3.2, 27.7.4, and 27.7.6</p>
<p>Replace</p>
<pre>
  basic_stringbuf&lt;charT,traits,Allocator&gt;* rdbuf() const;
</pre>
<p>with</p>
<pre>
  basic_stringbuf&lt;charT,traits,Allocator&gt;* rdbuf();
  const basic_stringbuf&lt;charT,traits,Allocator&gt;* rdbuf() const;
</pre>

<p>In  27.8.1.5, 27.8.1.7, 27.8.1.8, 27.8.1.10, 27.8.1.11, and 27.8.1.13</p>
<p>Replace</p>
<pre>
  basic_filebuf&lt;charT,traits&gt;* rdbuf() const;
</pre>
<p>with</p>
<pre>
  basic_filebuf&lt;charT,traits&gt;* rdbuf();
  const basic_filebuf&lt;charT,traits&gt;* rdbuf() const;
</pre>
<hr>
<a name="368"><h3>368.&nbsp;basic_string::replace has two &quot;Throws&quot; paragraphs</h3></a><p>
<b>Section:</b>&nbsp;21.3.5.6 <a href="lib-strings.html#lib.string::replace"> [lib.string::replace]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Beman Dawes&nbsp; <b>Date:</b>&nbsp;3 Jun 2002</p>
<p>
21.3.5.6 <a href="lib-strings.html#lib.string::replace"> [lib.string::replace]</a> basic_string::replace, second
signature, given in paragraph 1, has two &quot;Throws&quot; paragraphs (3 and
5).
</p>

<p>
In addition, the second &quot;Throws&quot; paragraph (5) includes specification
(beginning with &quot;Otherwise, the function replaces ...&quot;) that should be
part of the &quot;Effects&quot; paragraph.
</p>
<p><b>Proposed resolution:</b></p>
<p><i>[This is a typo that escalated.  It's clear that what's in the
  Standard is wrong.  It's less clear what the fix ought to be.
  Someone who understands string replace well needs to work on
  this.]</i></p>
<hr>
<a name="369"><h3>369.&nbsp;io stream objects and static ctors</h3></a><p>
<b>Section:</b>&nbsp;27.3 <a href="lib-iostreams.html#lib.iostream.objects"> [lib.iostream.objects]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Ruslan Abdikeev&nbsp; <b>Date:</b>&nbsp;8 Jul 2002</p>
<p>
Is it safe to use standard iostream objects from constructors of
static objects?  Are standard iostream objects constructed and are
their associations established at that time?
</p>

<p>Surpisingly enough, Standard does NOT require that.</p>

<p>
27.3/2 [lib.iostream.objects] guarantees that standard iostream
objects are constructed and their associations are established before
the body of main() begins execution.  It also refers to ios_base::Init
class as the panacea for constructors of static objects.
</p>

<p>
However, there's nothing in 27.3 [lib.iostream.objects],
in 27.4.2 [lib.ios.base], and in 27.4.2.1.6 [lib.ios::Init],
that would require implementations to allow access to standard
iostream objects from constructors of static objects.
</p>

<p>Details:</p>

<p>Core text refers to some magic object ios_base::Init, which will
be discussed below:</p>

<blockquote>
    &quot;The [standard iostream] objects are constructed, and their
    associations are established at some time prior to or during
    first time an object of class basic_ios&lt;charT,traits&gt;::Init
    is constructed, and in any case before the body of main
    begins execution.&quot; (27.3/2 [lib.iostream.objects])
</blockquote>

<p>
The first <i>non-normative</i> footnote encourages implementations
to initialize standard iostream objects earlier than required.
</p>

<p>However, the second <i>non-normative</i> footnote makes an explicit
and unsupported claim:</p>

<blockquote>
  &quot;Constructors and destructors for static objects can access these
  [standard iostream] objects to read input from stdin or write output
  to stdout or stderr.&quot; (27.3/2 footnote 265 [lib.iostream.objects])
</blockquote>

<p>
The only bit of magic is related to that ios_base::Init class.  AFAIK,
the rationale behind ios_base::Init was to bring an instance of this
class to each translation unit which #included &lt;iostream&gt; or
related header.  Such an inclusion would support the claim of footnote
quoted above, because in order to use some standard iostream object it
is necessary to #include &lt;iostream&gt;.
</p>

<p>
However, while Standard explicitly describes ios_base::Init as
an appropriate class for doing the trick, I failed to found a
mention of an _instance_ of ios_base::Init in Standard.
</p>
<p><b>Proposed resolution:</b></p>
<p>
At the end of header &lt;iostream&gt; synopsis in 27.3 <a href="lib-iostreams.html#lib.iostream.objects"> [lib.iostream.objects]</a>
</p>

<pre>
       namespace std
       {
          ... extern istream cin; ...
</pre>

<p>add the following lines</p>

<pre>
          namespace
          {
             ios_base::Init &lt;some_implementation_defined_name&gt;;
          }
        }
</pre>

<p><i>[Santa Cruz: The LWG is leaning toward NAD.  There isn't any
normative wording saying that the Init scheme will be used, but that
is probably intentional.  Implementers use dirty tricks for iostream
initialization, and doing it portably is somewhere between difficult
and impossible.  Too much constraint in this area is dangerous, and if
we are to make any changes it would probably be more appropriate
forthem to be nonnormative.  Martin will try to come up with clearer
wording that expreses this intent.]</i></p>


<hr>
<a name="371"><h3>371.&nbsp;Stability of multiset and multimap member functions</h3></a><p>
<b>Section:</b>&nbsp;23.1 <a href="lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Frank Compagner&nbsp; <b>Date:</b>&nbsp;20 Jul 2002</p>
<p>
The requirements for multiset and multimap containers (23.1
[lib.containers.requirements], 23.1.2 [lib.associative.reqmnts],
23.3.2 [lib.multimap] and 23.3.4 [lib.multiset]) make no mention of
the stability of the required (mutating) member functions. It appears
the standard allows these functions to reorder equivalent elements of
the container at will, yet the pervasive red-black tree implementation
appears to provide stable behaviour.
</p>

<p>This is of most concern when considering the behaviour of erase().
A stability requirement would guarantee the correct working of the
following 'idiom' that removes elements based on a certain predicate
function.
</p>

<pre>
  multimap&lt;int, int&gt; m;
  multimap&lt;int, int&gt;::iterator i = m.begin();
  while (i != m.end()) {
      if (pred(i))
          m.erase (i++);
      else
          ++i;
  }
</pre>

<p>
Although clause 23.1.2/8 guarantees that i remains a valid iterator
througout this loop, absence of the stability requirement could
potentially result in elements being skipped. This would make
this code incorrect, and, furthermore, means that there is no way
of erasing these elements without iterating first over the entire
container, and second over the elements to be erased. This would
be unfortunate, and have a negative impact on both performance and
code simplicity.
</p>

<p>
If the stability requirement is intended, it should be made explicit
(probably through an extra paragraph in clause 23.1.2).
</p>
<p>
If it turns out stability cannot be guaranteed, i'd argue that a
remark or footnote is called for (also somewhere in clause 23.1.2) to
warn against relying on stable behaviour (as demonstrated by the code
above).  If most implementations will display stable behaviour, any
problems emerging on an implementation without stable behaviour will
be hard to track down by users. This would also make the need for an
erase_if() member function that much greater.
</p>

<p>This issue is somewhat related to LWG issue <a href="lwg-closed.html#130">130</a>.</p>

<p><i>[Santa Cruz: More people need to look at this.  Much user code
  may assume stability.  On the other hand, it seems drastic to add a
  new requirement now.]</i></p>

<p><b>Proposed resolution:</b></p>
<hr>
<a name="376"><h3>376.&nbsp;basic_streambuf semantics</h3></a><p>
<b>Section:</b>&nbsp;27.7.1.3 <a href="lib-iostreams.html#lib.stringbuf.virtuals"> [lib.stringbuf.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Ray Lischner&nbsp; <b>Date:</b>&nbsp;14 Aug 2002</p>
<p>
In Section 27.7.1.3 <a href="lib-iostreams.html#lib.stringbuf.virtuals"> [lib.stringbuf.virtuals]</a>, Table 90, the implication is that
the four conditions should be mutually exclusive, but they are not.
The first two cases, as written, are subcases of the third. I think it
would be clearer if the conditions were rewritten as follows:
</p>

<blockquote>
<p>
  (which &amp; (ios_base::in|ios_base::out)) == ios_base::in
</p>

<p>
  (which &amp; (ios_base::in|ios_base::out)) == ios_base::out
</p>

<p>
  (which &amp; (ios_base::in|ios_base::out)) == 
(ios_base::in|ios_base::out)
   and way == either ios_base::beg or ios_base::end
</p>

<p>Otherwise</p>
</blockquote>

<p>
As written, it is unclear what should be the result if cases 1 &amp; 2
are true, but case 3 is false, e.g.,
</p>

<blockquote>
  seekoff(0, ios_base::cur, ios_base::in | ios_base::out)
</blockquote>

<p><i>[Santa Cruz: The ambiguity seems real.  We need to do a survey of
implementations before we decide on a solution.]</i></p>

<p><b>Proposed resolution:</b></p>
<hr>
<a name="378"><h3>378.&nbsp;locale immutability and locale::operator=()</h3></a><p>
<b>Section:</b>&nbsp;22.1.1 <a href="lib-locales.html#lib.locale"> [lib.locale]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;6 Sep 2002</p>
<p>
I think there is a problem with 22.1.1, p6 which says that
</p>
<pre>
    -6- An instance of locale is immutable; once a facet reference
        is obtained from it, that reference remains usable as long
        as the locale value itself exists.
</pre>
<p>
and 22.1.1.2, p4:
</p>
<pre>
    const locale&amp; operator=(const locale&amp; other) throw();

    -4- Effects: Creates a copy of other, replacing the current value.
</pre>
<p>
How can a reference to a facet obtained from a locale object remain
valid after an assignment that clearly must replace all the facets
in the locale object? Imagine a program such as this
</p>
<pre>
    std::locale loc (&quot;de_DE&quot;);
    const std::ctype&lt;char&gt; &amp;r0 = std::use_facet&lt;std::ctype&lt;char&gt; &gt;(loc);
    loc = std::locale (&quot;en_US&quot;);
    const std::ctype&lt;char&gt; &amp;r1 = std::use_facet&lt;std::ctype&lt;char&gt; &gt;(loc);
</pre>
<p>
Is r0 really supposed to be preserved and destroyed only when loc goes
out of scope?
</p>
<p><b>Proposed resolution:</b></p>
<p>
Suggest to replace 22.1.1 <a href="lib-locales.html#lib.locale"> [lib.locale]</a>, p6 with
</p>
<pre>
    -6- Unless assigned a new value, locale objects are immutable;
        once a facet reference is obtained from it, that reference
        remains usable as long as the locale object itself exists
        or until the locale object is assigned the value of another,
        distinct locale object.
</pre>

<p><i>[Santa Cruz: Dietmar agrees with this general direction, but is
uncomfortable about the proposed wording.  He and Martin will try to
come up with better wording.]</i></p>

<hr>
<a name="379"><h3>379.&nbsp;nonsensical ctype::do_widen() requirement</h3></a><p>
<b>Section:</b>&nbsp;22.2.1.1.2 <a href="lib-locales.html#lib.locale.ctype.virtuals"> [lib.locale.ctype.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Review">Review</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;6 Sep 2002</p>
<p>
The last sentence in 22.2.1.1.2, p11 below doesn't seem to make sense.
</p>
<pre>
  charT do_widen (char c) const;

  -11- Effects: Applies the simplest reasonable transformation from
       a char value or sequence of char values to the corresponding
       charT value or values. The only characters for which unique
       transformations are required are those in the basic source
       character set (2.2). For any named ctype category with a
       ctype&lt;charT&gt; facet ctw and valid ctype_base::mask value
       M (is(M, c) || !ctw.is(M, do_widen(c))) is true.
</pre>
<p>
Shouldn't the last sentence instead read
</p>
<pre>
       For any named ctype category with a ctype&lt;char&gt; facet ctc
       and valid ctype_base::mask value M
       (ctc.is(M, c) || !is(M, do_widen(c))) is true.
</pre>
<p>
I.e., if the narrow character c is not a member of a class of
characters then neither is the widened form of c. (To paraphrase
footnote 224.)
</p>
<p><b>Proposed resolution:</b></p>
<p>
Replace the last sentence of 22.2.1.1.2 <a href="lib-locales.html#lib.locale.ctype.virtuals"> [lib.locale.ctype.virtuals]</a>, p11 with the
following text:
</p>
<pre>
       For any named ctype category with a ctype&lt;char&gt; facet ctc
       and valid ctype_base::mask value M
       (ctc.is(M, c) || !is(M, do_widen(c))) is true.
</pre>
<p><b>Rationale:</b></p>
<p>The LWG believes this is just a typo, and that this is the correct fix.</p>
<hr>
<a name="382"><h3>382.&nbsp;codecvt do_in/out result</h3></a><p>
<b>Section:</b>&nbsp;22.2.1.5 <a href="lib-locales.html#lib.locale.codecvt"> [lib.locale.codecvt]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Review">Review</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;30 Aug  2002</p>
<p>
It seems that the descriptions of codecvt do_in() and do_out() leave
sufficient room for interpretation so that two implementations of
codecvt may not work correctly with the same filebuf. Specifically,
the following seems less than adequately specified:
</p>

<ol>
<li>
  the conditions under which the functions terminate
</li>
<li>
  precisely when the functions return ok
</li>
<li>
  precisely when the functions return partial
</li>
<li>
  the full set of conditions when the functions return error
</li>
</ol>

<ol>
<li>
   22.2.1.5.2 <a href="lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a>, p2 says this about the effects of the
   function: ...Stops if it encounters a character it cannot
   convert...  This assumes that there *is* a character to
   convert. What happens when there is a sequence that doesn't form a
   valid source character, such as an unassigned or invalid UNICODE
   character, or a sequence that cannot possibly form a character
   (e.g., the sequence &quot;\xc0\xff&quot; in UTF-8)?
</li>
<li>
   Table 53 says that the function returns codecvt_base::ok
   to indicate that the function(s) &quot;completed the conversion.&quot;
   Suppose that the source sequence is &quot;\xc0\x80&quot; in UTF-8,
   with from pointing to '\xc0' and (from_end==from + 1).
   It is not clear whether the return value should be ok
   or partial (see below).
</li>
<li>
   Table 53 says that the function returns codecvt_base::partial
   if &quot;not all source characters converted.&quot; With the from pointers
   set up the same way as above, it is not clear whether the return
   value should be partial or ok (see above).
</li>
<li>
   Table 53, in the row describing the meaning of error mistakenly
   refers to a &quot;from_type&quot; character, without the symbol from_type
   having been defined. Most likely, the word &quot;source&quot; character
   is intended, although that is not sufficient. The functions
   may also fail when they encounter an invalid source sequence
   that cannot possibly form a valid source character (e.g., as
   explained in bullet 1 above).
</li>
</ol>
<p>
Finally, the conditions described at the end of 22.2.1.5.2 <a href="lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a>, p4 don't seem to be possible:
</p>
<blockquote>
    &quot;A return value of partial, if (from_next == from_end),
    indicates that either the destination sequence has not
    absorbed all the available destination elements, or that
    additional source elements are needed before another
    destination element can be produced.&quot;
</blockquote>
<p>
If the value is partial, it's not clear to me that (from_next
==from_end) could ever hold if there isn't enough room
in the destination buffer. In order for (from_next==from_end) to
hold, all characters in that range must have been successfully
converted (according to 22.2.1.5.2 <a href="lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a>, p2) and since there are no
further source characters to convert, no more room in the
destination buffer can be needed.
</p>
<p>
It's also not clear to me that (from_next==from_end) could ever
hold if additional source elements are needed to produce another
destination character (not element as incorrectly stated in the
text). partial is returned if &quot;not all source characters have
been converted&quot; according to Table 53, which also implies that
(from_next==from) does NOT hold.
</p>
<p>
Could it be that the intended qualifying condition was actually
(from_next != from_end), i.e., that the sentence was supposed
to read
</p>
<blockquote>
    &quot;A return value of partial, if (from_next != from_end),...&quot;
</blockquote>
<p>
which would make perfect sense, since, as far as I understand it,
partial can only occur if (from_next != from_end)?
</p>
<p><b>Proposed resolution:</b></p>
<p>
To address these issues, I propose that paragraphs 2, 3, and 4
be rewritten as follows. The proposal incorporates the accepted
resolution of lwg issue 19.
</p>
<pre>
-2- Effects: Converts characters in the range of source elements
    [from, from_end), placing the results in sequential positions
    starting at destination to. Converts no more than (from_end &shy; from)
    source elements, and stores no more than (to_limit &shy; to)
    destination elements.

    Stops if it encounters a sequence of source elements it cannot
    convert to a valid destination character. It always leaves the
    from_next and to_next pointers pointing one beyond the last
    element successfully converted.

    [Note: If returns noconv, internT and externT are the same type
    and the converted sequence is identical to the input sequence
    [from, from_next). to_next is set equal to to, the value of
    state is unchanged, and there are no changes to the values in
    [to, to_limit). --end note]

-3- Notes: Its operations on state are unspecified.
    [Note: This argument can be used, for example, to maintain shift
    state, to specify conversion options (such as count only), or to
    identify a cache of seek offsets. --end note]

-4- Returns: An enumeration value, as summarized in Table 53:

    Table 53 -- do_in/do_out result values

     Value      Meaning
    +---------+----------------------------------------------------+
    | ok      | successfully completed the conversion of all       |
    |         | complete characters in the source range            |
    +---------+----------------------------------------------------+
    | partial | the characters in the source range would, after    |
    |         | conversion, require space greater than that        |
    |         | available in the destination range                 |
    +---------+----------------------------------------------------+
    | error   | encountered either a sequence of elements in the   |
    |         | source range forming a valid source character that |
    |         | could not be converted to a destination character, |
    |         | or a sequence of elements in the source range that |
    |         | could not possibly form a valid source character   |
    +---------+----------------------------------------------------+
    | noconv  | internT and externT are the same type, and input   |
    |         | sequence is identical to converted sequence        |
    +---------+----------------------------------------------------+

    A return value of partial, i.e., if (from_next != from_end),
    indicates that either the destination sequence has not absorbed
    all the available destination elements, or that additional
    source elements are needed before another destination character
    can be produced.
</pre>

<p><i>[Santa Cruz: The LWG agrees that this is an important issue and
that this general direction is probably correct.  Dietmar, Howard,
PJP, and Matt will review this wording.]</i></p>

<hr>
<a name="384"><h3>384.&nbsp;equal_range has unimplementable runtime complexity</h3></a><p>
<b>Section:</b>&nbsp;25.3.3.3 <a href="lib-algorithms.html#lib.equal.range"> [lib.equal.range]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Hans Bos&nbsp; <b>Date:</b>&nbsp;18 Oct 2002</p>
<p>
Section 25.3.3.3 <a href="lib-algorithms.html#lib.equal.range"> [lib.equal.range]</a>
states that at most 2 * log(last - first) + 1
comparisons are allowed for equal_range.
</p>

<p>It is not possible to implement equal_range with these constraints.</p>

<p>In a range of one element as in:</p>
<pre>
    int x = 1;
    equal_range(&amp;x, &amp;x + 1, 1)
</pre>

<p>it is easy to see that at least 2 comparison operations are needed.</p>

<p>For this case at most 2 * log(1) + 1 = 1 comparison is allowed.</p>

<p>I have checked a few libraries and they all use the same (nonconforming)
algorithm for equal_range that has a complexity of</p>
<pre>
     2* log(distance(first, last)) + 2.
</pre>
<p>I guess this is the algorithm that the standard assumes for equal_range.</p>

<p>
It is easy to see that 2 * log(distance) + 2 comparisons are enough
since equal range can be implemented with lower_bound and upper_bound
(both log(distance) + 1).
</p>

<p>
I think it is better to require something like 2log(distance) + O(1)  (or
even logarithmic as multiset::equal_range).
Then an implementation has more room to optimize for certain cases (e.g.
have log(distance) characteristics when at most match is found in the range
but 2log(distance) + 4 for the worst case).
</p>

<p><i>[Santa Cruz: The issue is real, but of greater scope than just
equal_range: it affects all of the binary search algorithms.  What is
the complexity supposed to be for ranges of 0 or 1 elements?  What
base are we using for the logarithm?  Are these bounds supposed to be
exact, or asymptotic?  (If the latter, of course, then none of the
other questions matter.)]</i></p>

<p><b>Proposed resolution:</b></p>
<hr>
<a name="385"><h3>385.&nbsp;Does call by value imply the CopyConstructible requirement?</h3></a><p>
<b>Section:</b>&nbsp;17 <a href="lib-intro.html#lib.library"> [lib.library]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;23 Oct 2002</p>
<p>
Many function templates have parameters that are passed by value;
a typical example is <tt>find_if</tt>'s <i>pred</i> parameter in
25.1.2 <a href="lib-algorithms.html#lib.alg.find"> [lib.alg.find]</a>.  Are the corresponding template parameters
(<tt>Predicate</tt> in this case) implicitly required to be
CopyConstructible, or does that need to be spelled out explicitly?
</p>

<p>
This isn't quite as silly a question as it might seem to be at first
sight.  If you call <tt>find_if</tt> in such a way that template
argument deduction applies, then of course you'll get call by value
and you need to provide a copy constructor.  If you explicitly provide
the template arguments, however, you can force call by reference by
writing something like <tt>find_if&lt;my_iterator,
my_predicate&amp;&gt;</tt>.  The question is whether implementation
are required to accept this, or whether this is ill-formed because
my_predicate&amp; is not CopyConstructible.
</p>

<p>
The scope of this problem, if it is a problem, is unknown.  Function
object arguments to generic algorithms in clauses 25 <a href="lib-algorithms.html#lib.algorithms"> [lib.algorithms]</a>
and 26 <a href="lib-numerics.html#lib.numerics"> [lib.numerics]</a> are obvious examples.  A review of the whole
library is necessary.
</p>
<p><b>Proposed resolution:</b></p>
<p><i>[
This is really two issues.  First, predicates are typically passed by
value but we don't say they must be Copy Constructible.  They should
be. Second: is specialization allowed to transform value arguments
into references? References aren't copy constructible, so this should
not be allowed.
]</i></p>
<hr>
<a name="386"><h3>386.&nbsp;Reverse iterator's operator[] has impossible return type</h3></a><p>
<b>Section:</b>&nbsp;24.4.1.3.11 <a href="lib-iterators.html#lib.reverse.iter.opindex"> [lib.reverse.iter.opindex]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;23 Oct 2002</p>
<p>In 24.4.1.3.11 <a href="lib-iterators.html#lib.reverse.iter.opindex"> [lib.reverse.iter.opindex]</a>, <tt>reverse_iterator&lt;&gt;::operator[]</tt> 
is specified as having a return type of <tt>reverse_iterator::reference</tt>,
which is the same as <tt>iterator_traits&lt;Iterator&gt;::reference</tt>.
(Where <tt>Iterator</tt> is the underlying iterator type.)</p>

<p>The trouble is that <tt>Iterator</tt>'s own operator[] doesn't
  necessarily have a return type
  of <tt>iterator_traits&lt;Iterator&gt;::reference</tt>.   Its
  return type is merely required to be convertible
  to <tt>Iterator</tt>'s value type.  The return type specified for
  reverse_iterator's operator[] would thus appear to be impossible.</p>

<p>Related issue: <a href="lwg-active.html#299">299</a>.  Jeremy will work on this.</p>
<p><b>Proposed resolution:</b></p>
<p><i>[
Comments from Dave Abrahams: IMO we should resolve 386 by just saying
    that the return type of reverse_iterator's operator[] is
    unspecified, allowing the random access iterator requirements to
    impose an appropriate return type.  If we accept 299's proposed
    resolution (and I think we should), the return type will be
    readable and writable, which is about as good as we can do.
]</i></p>
<hr>
<a name="387"><h3>387.&nbsp;std::complex over-encapsulated</h3></a><p>
<b>Section:</b>&nbsp;26.2 <a href="lib-numerics.html#lib.complex.numbers"> [lib.complex.numbers]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Review">Review</a>&nbsp; <b>Submitter:</b>&nbsp;Gabriel Dos Reis&nbsp; <b>Date:</b>&nbsp;8 Nov 2002</p>
<p>
The absence of explicit description of std::complex&lt;T&gt; layout
makes it imposible to reuse existing software developed in traditional
languages like Fortran or C with unambigous and commonly accepted
layout assumptions.  There ought to be a way for practitioners to
predict with confidence the layout of std::complex&lt;T&gt; whenever T
is a numerical datatype.  The absence of ways to access individual
parts of a std::complex&lt;T&gt; object as lvalues unduly promotes
severe pessimizations. For example, the only way to change,
independently, the real and imaginary parts is to write something like
</p>

<pre>
complex&lt;T&gt; z;
// ...
// set the real part to r
z = complex&lt;T&gt;(r, z.imag());
// ...
// set the imaginary part to i
z = complex&lt;T&gt;(z.real(), i);
</pre>

<p>
At this point, it seems appropriate to recall that a complex number
is, in effect, just a pair of numbers with no particular invariant to
maintain.  Existing practice in numerical computations has it that a
complex number datatype is usually represented by Cartesian
coordinates. Therefore the over-encapsulation put in the specification
of std::complex&lt;&gt; is not justified.
</p>

<p><b>Proposed resolution:</b></p>
<p>Add the following requirements to 26.2 <a href="lib-numerics.html#lib.complex.numbers"> [lib.complex.numbers]</a> as 26.2/4:</p>
<blockquote>
<p>If z is an lvalue expression of type cv std::complex&lt;T&gt; then</p>

<ul>
<li>the expression reinterpret_cast&lt;cv T(&amp;)[2]&gt;(z)
is well-formed; and</li>
<li>reinterpret_cast&lt;cvT(&amp;)[2]&gt;(z)[0]designates the
real part of z; and</li>
<li>reinterpret_cast&lt;cvT(&amp;)[2]&gt;(z)[1]designates the
imaginary part of z.</li>
</ul>

<p>
Moreover, if a is an expression of pointer type cv complex&lt;T&gt;*
and the expression a[i] is well-defined for an integer expression
i then:
</p>

<ul>
<li>reinterpret_cast&lt;cvT*&gt;(a)[2+i] designates the real
part of a[i]; and</li>
<li>reinterpret_cast&lt;cv T*&gt;(a)[2+i+1] designates the
imaginary part of a[i].</li>
</ul>
</blockquote>

<p>In the header synopsis in 26.2.1 <a href="lib-numerics.html#lib.complex.synopsis"> [lib.complex.synopsis]</a>, replace</p>
<pre>
  template&lt;class T&gt; T real(const complex&lt;T&gt;&amp;);
  template&lt;class T&gt; T imag(const complex&lt;T&gt;&amp;);
</pre>

<p>with</p>

<pre>
  template&lt;class T&gt; const T&amp; real(const complex&lt;T&gt;&amp;);
  template&lt;class T&gt;       T&amp; real(      complex&lt;T&gt;&amp;);
  template&lt;class T&gt; const T&amp; imag(const complex&lt;T&gt;&amp;);
  template&lt;class T&gt;       T&amp; imag(      complex&lt;T&gt;&amp;);
</pre>

<p>In 26.2.7 <a href="lib-numerics.html#lib.complex.value.ops"> [lib.complex.value.ops]</a> paragraph 1, change</p>
<pre>
  template&lt;class T&gt; T real(const complex&lt;T&gt;&amp;);
</pre>
<p>to</p>
<pre>
  template&lt;class T&gt; const T&amp; real(const complex&lt;T&gt;&amp;);
  template&lt;class T&gt;       T&amp; real(      complex&lt;T&gt;&amp;);
</pre>
<p>and change the <b>Returns</b> clause to &quot;<b>Returns:</b> The real
part of <i>x</i>
</p>.

<p>In 26.2.7 <a href="lib-numerics.html#lib.complex.value.ops"> [lib.complex.value.ops]</a> paragraph 2, change</p>
<pre>
  template&lt;class T&gt; T imag(const complex&lt;T&gt;&amp;);
</pre>
<p>to</p>
<pre>
  template&lt;class T&gt; const T&amp; imag(const complex&lt;T&gt;&amp;);
  template&lt;class T&gt;       T&amp; imag(      complex&lt;T&gt;&amp;);
</pre>
<p>and change the <b>Returns</b> clause to &quot;<b>Returns:</b> The imaginary
part of <i>x</i>
</p>.


<p><b>Rationale:</b></p>
<p>The LWG believes that C99 compatibility would be enough
justification for this change even without other considerations.  All
existing implementations already have the layout proposed here.</p>
<hr>
<a name="389"><h3>389.&nbsp;Const overload of valarray::operator[] returns by value</h3></a><p>
<b>Section:</b>&nbsp;26.3.2 <a href="lib-numerics.html#lib.template.valarray"> [lib.template.valarray]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Review">Review</a>&nbsp; <b>Submitter:</b>&nbsp;Gabriel Dos Reis&nbsp; <b>Date:</b>&nbsp;8 Nov 2002</p>
<p>Consider the following program:</p>
<pre>
    #include &lt;iostream&gt;
    #include &lt;ostream&gt;
    #include &lt;vector&gt;
    #include &lt;valarray&gt;
    #include &lt;algorithm&gt;
    #include &lt;iterator&gt;
    template&lt;typename Array&gt;
    void print(const Array&amp; a)
    {
    using namespace std;
    typedef typename Array::value_type T;
    copy(&amp;a[0], &amp;a[0] + a.size(),
    ostream_iterator&lt;T&gt;(std::cout, &quot; &quot;));
    }
    template&lt;typename T, unsigned N&gt;
    unsigned size(T(&amp;)[N]) { return N; }
    int main()
    {
    double array[] = { 0.89, 9.3, 7, 6.23 };
    std::vector&lt;double&gt; v(array, array + size(array));
    std::valarray&lt;double&gt; w(array, size(array));
    print(v); // #1
    std::cout &lt;&lt; std::endl;
    print(w); // #2
    std::cout &lt;&lt; std::endl;
    }
</pre>

<p>While the call numbered #1 succeeds, the call numbered #2 fails
because the const version of the member function
valarray&lt;T&gt;::operator[](size_t) returns a value instead of a
const-reference. That seems to be so for no apparent reason, no
benefit. Not only does that defeats users' expectation but it also
does hinder existing software (written either in C or Fortran)
integration within programs written in C++.  There is no reason why
subscripting an expression of type valarray&lt;T&gt; that is const-qualified
should not return a const T&amp;.</p>
<p><b>Proposed resolution:</b></p>
<p>In the class synopsis in 26.3.2 <a href="lib-numerics.html#lib.template.valarray"> [lib.template.valarray]</a>, and in
26.3.2.3 <a href="lib-numerics.html#lib.valarray.access"> [lib.valarray.access]</a> just above paragraph 1, change</p>
<pre>
  T operator[](size_t const;)
</pre>
<p>to</p>
<pre>
  const T&amp; operator[](size_t const;)
</pre>

<p><b>Rationale:</b></p>
<p>Return by value seems to serve no purpose.  Valaray was explicitly
designed to have a specified layout so that it could easily be
integrated with libraries in other languages, and return by value
defeats that purpose.  It is believed that this change will have no
impact on allowable optimizations.</p>
<hr>
<a name="391"><h3>391.&nbsp;non-member functions specified as const</h3></a><p>
<b>Section:</b>&nbsp;22.1.3.2 <a href="lib-locales.html#lib.conversions"> [lib.conversions]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Review">Review</a>&nbsp; <b>Submitter:</b>&nbsp;James Kanze&nbsp; <b>Date:</b>&nbsp;10 Dec 2002</p>
<p>
The specifications of toupper and tolower both specify the functions as
const, althought they are not member functions, and are not specified as
const in the header file synopsis in section 22.1 <a href="lib-locales.html#lib.locales"> [lib.locales]</a>.
</p>
<p><b>Proposed resolution:</b></p>
<p>In 22.1.3.2 <a href="lib-locales.html#lib.conversions"> [lib.conversions]</a>, remove <tt>const</tt> from the function
  declarations of std::toupper and std::tolower</p>
<p><b>Rationale:</b></p>
<p>Fixes an obvious typo</p>
<hr>
<a name="394"><h3>394.&nbsp;behavior of formatted output on failure</h3></a><p>
<b>Section:</b>&nbsp;27.6.2.5 <a href="lib-iostreams.html#lib.ostream.formatted"> [lib.ostream.formatted]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Review">Review</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;27 Dec 2002</p>
<p>
There is a contradiction in Formatted output about what bit is
supposed to be set if the formatting fails. On sentence says it's
badbit and another that it's failbit.
</p>
<p>
27.6.2.5.1, p1 says in the Common Requirements on Formatted output
functions:
<pre>
     ... If the generation fails, then the formatted output function
     does setstate(ios::failbit), which might throw an exception.
</pre>
</p>
<p>
27.6.2.5.2, p1 goes on to say this about Arithmetic Inserters:
</p>
<p>
     ... The formatting conversion occurs as if it performed the
     following code fragment:
</p>
<p>
<pre>
     bool failed =
         use_facet&lt;num_put&lt;charT,ostreambuf_iterator&lt;charT,traits&gt;
         &gt; &gt;
         (getloc()).put(*this, *this, fill(), val). failed();

     ... If failed is true then does setstate(badbit) ...
</pre>
</p>
<p>
The original intent of the text, according to Jerry Schwarz (see
c++std-lib-10500), is captured in the following paragraph:
</p>
<p>
In general &quot;badbit&quot; should mean that the stream is unusable because
of some underlying failure, such as disk full or socket closure;
&quot;failbit&quot; should mean that the requested formatting wasn't possible
because of some inconsistency such as negative widths.  So typically
if you clear badbit and try to output something else you'll fail
again, but if you clear failbit and try to output something else
you'll succeed.
</p>
<p>
In the case of the arithmetic inserters, since num_put cannot
report failure by any means other than exceptions (in response
to which the stream must set badbit, which prevents the kind of
recoverable error reporting mentioned above), the only other
detectable failure is if the iterator returned from num_put
returns true from failed().
</p>
<p>
Since that can only happen (at least with the required iostream
specializations) under such conditions as the underlying failure
referred to above (e.g., disk full), setting badbit would seem
to be the appropriate response (indeed, it is required in
27.6.2.5.2, p1). It follows that failbit can never be directly
set by the arithmetic (it can only be set by the sentry object
under some unspecified conditions).
</p>
<p>
The situation is different for other formatted output functions
which can fail as a result of the streambuf functions failing
(they may do so by means other than exceptions), and which are
then required to set failbit.
</p>
<p>
The contradiction, then, is that ostream::operator&lt;&lt;(int) will
set badbit if the disk is full, while operator&lt;&lt;(ostream&amp;,
char) will set failbit under the same conditions. To make the behavior
consistent, the Common requirements sections for the Formatted output
functions should be changed as proposed below.
</p>
<p><b>Proposed resolution:</b></p>
<p>
In paragraph one of section 27.6.2.5 <a href="lib-iostreams.html#lib.ostream.formatted"> [lib.ostream.formatted]</a>, delete the
sentence beginning with &quot;If the generation fails&quot;.
</p>
<p><b>Rationale:</b></p>
<p>
There isn't any contradiction here. <tt>put</tt> returns a streambuf iterator.
<tt>failed()</tt> is a member function of the streambuf iterator.  If
it's set then that's a streambuf error, not a conversion error.
</p>

<p>
The real problem isn't that there's a contradiction, but that the &quot;If
the generation fails&quot; part makes little sense.  &quot;Generation&quot; isn't
clearly defined.  It's not clear what it means for generation to
fail, or even whether it can fail.  The intention is probably that
generaion meant formatting, as opposed to character insertion, and
that this sentence was intended as analogous to character parsing.
</p>

<p>A more precise definition would be that we set failbit if the facet
  reports failure.  However, the mechanism for the facet reporting
  failure is that it sets failbit!  Saying that we set failbit if the
  facet sets failbit would be silly, so the best thing to say is
  nothing.</p>

<hr>
<a name="395"><h3>395.&nbsp;inconsistencies in the definitions of rand() and random_shuffle()</h3></a><p>
<b>Section:</b>&nbsp;26.5 <a href="lib-numerics.html#lib.c.math"> [lib.c.math]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Review">Review</a>&nbsp; <b>Submitter:</b>&nbsp;James Kanze&nbsp; <b>Date:</b>&nbsp;3 Jan 2003</p>
<p>
In 26.5 <a href="lib-numerics.html#lib.c.math"> [lib.c.math]</a>, the C++ standard refers to the C standard for the
definition of rand(); in the C standard, it is written that &quot;The
implementation shall behave as if no library function calls the rand
function.&quot;
</p>

<p>
In 25.2.11 <a href="lib-algorithms.html#lib.alg.random.shuffle"> [lib.alg.random.shuffle]</a>, there is no specification as to
how the two parameter version of the function generates its random
value.  I believe that all current implementations in fact call rand()
(in contradiction with the requirement avove); if an implementation does
not call rand(), there is the question of how whatever random generator
it does use is seeded.  Something is missing.
</p>

<p><b>Proposed resolution:</b></p>
<p>
In [lib.c.math], add a paragraph specifying that the C definition of
rand shal be modified to say that &quot;Unless otherwise specified, the
implementation shall behave as if no library function calls the rand
function.&quot;
</p>

<p>
In [lib.alg.random.shuffle], add a sentence to the effect that &quot;In
the two argument form of the function, the underlying source of
random numbers is implementation defined. [Note: in particular, an
implementation is permitted to use <tt>rand</tt>.]
</p>
<p><b>Rationale:</b></p>
<p>The original proposed resolution proposed requiring the
  two-argument from of <tt>random_shuffle</tt> to
  use <tt>rand</tt>. We don't want to do that, because some existing
  implementations already use something else: gcc
  uses <tt>lrand48</tt>, for example.  Using <tt>rand</tt> presents a
  problem if the number of elements in the sequence is greater than
  RAND_MAX.</p> 
<hr>
<a name="396"><h3>396.&nbsp;what are characters zero and one</h3></a><p>
<b>Section:</b>&nbsp;23.3.5.1 <a href="lib-containers.html#lib.bitset.cons"> [lib.bitset.cons]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Review">Review</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;5 Jan 2003</p>
    <p>
23.3.5.1, p6 [lib.bitset.cons] talks about a generic character
having the value of 0 or 1 but there is no definition of what
that means for charT other than char and wchar_t. And even for
those two types, the values 0 and 1 are not actually what is
intended -- the values '0' and '1' are. This, along with the
converse problem in the description of to_string() in 23.3.5.2,
p33, looks like a defect remotely related to DR 303.
    </p>
    <p>
http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#303
    </p>
    <pre>
23.3.5.1:
  -6-  An element of the constructed string has value zero if the
       corresponding character in str, beginning at position pos,
       is 0. Otherwise, the element has the value one.
    </pre>
    <pre>
23.3.5.2:
  -33-  Effects: Constructs a string object of the appropriate
        type and initializes it to a string of length N characters.
        Each character is determined by the value of its
        corresponding bit position in *this. Character position N
        ?- 1 corresponds to bit position zero. Subsequent decreasing
        character positions correspond to increasing bit positions.
        Bit value zero becomes the character 0, bit value one becomes
        the character 1.
    </pre>
    <p>
Also note the typo in 23.3.5.1, p6: the object under construction
is a bitset, not a string.
    </p>
  <p><b>Proposed resolution:</b></p>
<p>Change the constructor's function declaration immediately before 
23.3.5.1 <a href="lib-containers.html#lib.bitset.cons"> [lib.bitset.cons]</a> p3 to:</p>
<pre>
    template &lt;class charT, class traits, class Allocator&gt;
    explicit
    bitset(const basic_string&lt;charT, traits, Allocator&gt;&amp; str,
           typename basic_string&lt;charT, traits, Allocator&gt;::size_type pos = 0,
           typename basic_string&lt;charT, traits, Allocator&gt;::size_type n =
             basic_string&lt;charT, traits, Allocator&gt;::npos,
           charT zero = charT('0'));
</pre>
<p>Change the first two sentences of 23.3.5.1 <a href="lib-containers.html#lib.bitset.cons"> [lib.bitset.cons]</a> p6 to: &quot;An
element of the constructed string has value 0 if the corresponding
character in <i>str</i>, beginning at position <i>pos</i>,
is <i>zero</i>. Otherwise, the element has the value 1.</p>

<p>Change the declaration of the <tt>to_string</tt> member function
  immediately before 23.3.5.2 <a href="lib-containers.html#lib.bitset.members"> [lib.bitset.members]</a> p33 to:</p>
<pre>
    template &lt;class charT, class traits, class Allocator&gt;
    basic_string&lt;charT, traits, Allocator&gt; to_string(charT zero = charT('0')) const;
</pre>
<p>Change the last sentence of 23.3.5.2 <a href="lib-containers.html#lib.bitset.members"> [lib.bitset.members]</a> p33 to: &quot;Bit
  value 0 becomes the character <tt><i>zero</i></tt>, bit value 1 becomes the
  character <tt><i>zero</i> + 1</tt>.</p>
<p>Change 23.3.5.3 <a href="lib-containers.html#lib.bitset.operators"> [lib.bitset.operators]</a> p8 to:</p>
<p>
<b>Returns</b>:</p> 
<pre>
  os &lt;&lt; x.template to_string&lt;charT,traits,allocator&lt;charT&gt; &gt;(
      use_facet&lt;ctype&lt;charT&gt; &gt;(<i>os</i>.getloc()).widen('0'))
</pre>
<p><b>Rationale:</b></p>
<p>There is a real problem here: we need the character values of '0'
  and '1', and we have no way to get them since strings don't have
  imbued locales. In principle the &quot;right&quot; solution would be to
  provide an extra object, either a ctype facet or a full locale,
  which would be used to widen '0' and '1'. However, there was some
  discomfort about using such a heavyweight mechanism.  The proposed
  resolution allows those users who care about this issue to get it
  right.</p>
<p>Note that we only need one extra argument, because the character
  codes for digits are guaranteed to be contiguous.</p>
<p>We fix the inserter to use the new argument.  Note that we already
  fixed the analogous problem with the extractor in issue <a href="lwg-defects.html#303">303</a>.</p>

<hr>
<a name="397"><h3>397.&nbsp;ostream::sentry dtor throws exceptions</h3></a><p>
<b>Section:</b>&nbsp;27.6.2.3 <a href="lib-iostreams.html#lib.ostream::sentry"> [lib.ostream::sentry]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;5 Jan 2003</p>
    <p>
17.4.4.8, p3 prohibits library dtors from throwing exceptions.
    </p>
    <p>
27.6.2.3, p4 says this about the ostream::sentry dtor:
    </p>
    <pre>
    -4- If ((os.flags() &amp; ios_base::unitbuf) &amp;&amp; !uncaught_exception())
        is true, calls os.flush().
    </pre>
    <p>
27.6.2.6, p7 that describes ostream::flush() says:
    </p>
    <pre>
    -7- If rdbuf() is not a null pointer, calls rdbuf()-&gt;pubsync().
        If that function returns ?-1 calls setstate(badbit) (which
        may throw ios_base::failure (27.4.4.3)).
    </pre>
    <p>
That seems like a defect, since both pubsync() and setstate() can
throw an exception. 
    </p>
  <p><b>Proposed resolution:</b></p>
<p><i>[
The contradiction is real.  Clause 17 says destructors may never
throw exceptions, and clause 27 specifies a destructor that does
throw.  In principle we might change either one.  We're leaning
toward changing clause 17: putting in an &quot;unless otherwise specified&quot;
clause, and then putting in a footnote saying the sentry destructor
is the only one that can throw.
]</i></p>
<hr>
<a name="398"><h3>398.&nbsp;effects of end-of-file on unformatted input functions</h3></a><p>
<b>Section:</b>&nbsp;27.6.2.3 <a href="lib-iostreams.html#lib.ostream::sentry"> [lib.ostream::sentry]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;5 Jan 2003</p>
    <p>
While reviewing unformatted input member functions of istream
for their behavior when they encounter end-of-file during input
I found that the requirements vary, sometimes unexpectedly, and
in more than one case even contradict established practice (GNU
libstdc++ 3.2, IBM VAC++ 6.0, STLPort 4.5, SunPro 5.3, HP aCC
5.38, Rogue Wave libstd 3.1, and Classic Iostreams).
    </p>
    <p>
The following unformatted input member functions set eofbit if they
encounter an end-of-file (this is the expected behavior, and also
the behavior of all major implementations):
    </p>
    <p>
    <pre>
    basic_istream&lt;charT, traits&gt;&amp;
    get (char_type*, streamsize, char_type);
    </pre>
    </p>
    <p>
    Also sets failbit if it fails to extract any characters.
    </p>
    <p>
    <pre>
    basic_istream&lt;charT, traits&gt;&amp;
    get (char_type*, streamsize);
    </pre>
    </p>
    <p>
    Also sets failbit if it fails to extract any characters.
    </p>
    <p>
    <pre>
    basic_istream&lt;charT, traits&gt;&amp;
    getline (char_type*, streamsize, char_type);
    </pre>
    </p>
    <p>
    Also sets failbit if it fails to extract any characters.
    </p>
    <p>
    <pre>
    basic_istream&lt;charT, traits&gt;&amp;
    getline (char_type*, streamsize);
    </pre>
    </p>
    <p>
    Also sets failbit if it fails to extract any characters.
    </p>
    <p>
    <pre>
    basic_istream&lt;charT, traits&gt;&amp;
    ignore (int, int_type);
    </pre>
    </p>
    <p>
    <pre>
    basic_istream&lt;charT, traits&gt;&amp;
    read (char_type*, streamsize);
    </pre>
    </p>
    <p>
    Also sets failbit if it encounters end-of-file.
    </p>
    <p>
    <pre>
    streamsize readsome (char_type*, streamsize);
    </pre>
    </p>

    <p>
The following unformated input member functions set failbit but
not eofbit if they encounter an end-of-file (I find this odd
since the functions make it impossible to distinguish a general
failure from a failure due to end-of-file; the requirement is
also in conflict with all major implementation which set both
eofbit and failbit):
    </p>
    <p>
    <pre>
    int_type get();
    </pre>
    </p>
    <p>
    <pre>
    basic_istream&lt;charT, traits&gt;&amp;
    get (char_type&amp;);
    </pre>
    </p>
    <p>
These functions only set failbit of they extract no characters,
otherwise they don't set any bits, even on failure (I find this
inconsistency quite unexpected; the requirement is also in
conflict with all major implementations which set eofbit
whenever they encounter end-of-file):
    </p>
    <p>
    <pre>
    basic_istream&lt;charT, traits&gt;&amp;
    get (basic_streambuf&lt;charT, traits&gt;&amp;, char_type);
    </pre>
    </p>
    <p>
    <pre>
    basic_istream&lt;charT, traits&gt;&amp;
    get (basic_streambuf&lt;charT, traits&gt;&amp;);
    </pre>
    </p>
    <p>
This function sets no bits (all implementations except for
STLport and Classic Iostreams set eofbit when they encounter
end-of-file):
    </p>
    <p>
    <pre>
    int_type peek ();
    </pre>
    </p>
  <p><b>Proposed resolution:</b></p>
<p>Informally, what we want is a global statement of intent saying
  that eofbit gets set if we trip across EOF, and then we can take
  away the specific wording for individual functions.  A full review
  is necessary.  The wording currently in the standard is a mishmash,
  and changing it on an individual basis wouldn't make things better.
  Dietmar will do this work.</p>
<hr>
<a name="400"><h3>400.&nbsp;redundant type cast in lib.allocator.members</h3></a><p>
<b>Section:</b>&nbsp;20.4.1.1 <a href="lib-utilities.html#lib.allocator.members"> [lib.allocator.members]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Markus Mauhart&nbsp; <b>Date:</b>&nbsp;27 Feb 2003</p>
<p>
20.4.1.1 <a href="lib-utilities.html#lib.allocator.members"> [lib.allocator.members]</a> allocator members, contains
the following 3 lines:
</p>

<pre>
  12 Returns: new((void *) p) T( val)
     void destroy(pointer p);
  13 Returns: ((T*) p)-&gt;~T()
</pre>

<p>
The type cast &quot;(T*) p&quot; in the last line is redundant cause
we know that std::allocator&lt;T&gt;::pointer is a typedef for T*.
</p>
<p><b>Proposed resolution:</b></p>
<p>
Replace &quot;((T*) p)&quot; with &quot;p&quot;.
</p>
<p><b>Rationale:</b></p>
<p>Just a typo, this is really editorial.</p>
<hr>
<a name="401"><h3>401.&nbsp; incorrect type casts in table 32 in lib.allocator.requirements</h3></a><p>
<b>Section:</b>&nbsp;20.1.5 <a href="lib-utilities.html#lib.allocator.requirements"> [lib.allocator.requirements]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Markus Mauhart&nbsp; <b>Date:</b>&nbsp;27 Feb 2003</p>
<p>
I think that in par2 of 20.1.5 <a href="lib-utilities.html#lib.allocator.requirements"> [lib.allocator.requirements]</a> the last two
lines of table 32 contain two incorrect type casts. The lines are ...
</p>

<pre>
  a.construct(p,t)   Effect: new((void*)p) T(t)
  a.destroy(p)       Effect: ((T*)p)?-&gt;~T()
</pre>

<p>
.... with the prerequisits coming from the preceding two paragraphs, especially
from table 31:
</p>

<pre>
  alloc&lt;T&gt;             a     ;// an allocator for T
  alloc&lt;T&gt;::pointer    p     ;// random access iterator
                              // (may be different from T*)
  alloc&lt;T&gt;::reference  r = *p;// T&amp;
  T const&amp;             t     ;
</pre>

<p>
For that two type casts (&quot;(void*)p&quot; and &quot;(T*)p&quot;) to be well-formed
this would require then conversions to T* and void* for all
alloc&lt;T&gt;::pointer, so it would implicitely introduce extra
requirements for alloc&lt;T&gt;::pointer, additionally to the only
current requirement (being a random access iterator).
</p>
<p><b>Proposed resolution:</b></p>
<p>
&quot;(void*)p&quot; should be replaced with &quot;(void*)&amp;*p&quot; and that
&quot;((T*)p)?-&gt;&quot; should be replaced with &quot;(*p).&quot; or with
&quot;(&amp;*p)-&gt;&quot;.
</p>

<p>
Note: Actually I would prefer to replace &quot;((T*)p)?-&gt;dtor_name&quot; with
&quot;p?-&gt;dtor_name&quot;, but AFAICS this is not possible cause of an omission
in 13.5.6 <a href="over.html#over.ref"> [over.ref]</a> (for which I have filed another DR on 29.11.2002).
</p>
<hr>
<a name="402"><h3>402.&nbsp;wrong new expression in [some_]allocator::construct</h3></a><p>
<b>Section:</b>&nbsp;20.1.5 <a href="lib-utilities.html#lib.allocator.requirements"> [lib.allocator.requirements]</a>, 20.4.1.1 <a href="lib-utilities.html#lib.allocator.members"> [lib.allocator.members]</a>, &nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Markus Mauhart&nbsp; <b>Date:</b>&nbsp;27 Feb 2003</p>
<p>
This applies to the new expression that is contained in both par12 of
20.4.1.1 <a href="lib-utilities.html#lib.allocator.members"> [lib.allocator.members]</a> and in par2 (table 32) of 20.1.5 <a href="lib-utilities.html#lib.allocator.requirements"> [lib.allocator.requirements]</a>.
I think this new expression is wrong, involving unintended side
effects.
</p>


<p>20.4.1.1 <a href="lib-utilities.html#lib.allocator.members"> [lib.allocator.members]</a>  contains the following 3 lines:</p>

<pre>
  11 Returns: the largest value N for which the call allocate(N,0) might succeed.
     void construct(pointer p, const_reference val);
  12 Returns: new((void *) p) T( val)
</pre>


<p>20.1.5 <a href="lib-utilities.html#lib.allocator.requirements"> [lib.allocator.requirements]</a> in table 32 has the following line:</p>
<pre>
  a.construct(p,t)   Effect: new((void*)p) T(t)
</pre>

<p>
.... with the prerequisits coming from the preceding two paragraphs,
especially from table 31:
</p>

<pre>
  alloc&lt;T&gt;             a     ;// an allocator for T
  alloc&lt;T&gt;::pointer    p     ;// random access iterator
                              // (may be different from T*)
  alloc&lt;T&gt;::reference  r = *p;// T&amp;
  T const&amp;             t     ;
</pre>

<p>
Cause of using &quot;new&quot; but not &quot;::new&quot;, any existing &quot;T::operator new&quot;
function will hide the global placement new function. When there is no
&quot;T::operator new&quot; with adequate signature,
every_alloc&lt;T&gt;::construct(..) is ill-formed, and most
std::container&lt;T,every_alloc&lt;T&gt;&gt; use it; a workaround
would be adding placement new and delete functions with adequate
signature and semantic to class T, but class T might come from another
party. Maybe even worse is the case when T has placement new and
delete functions with adequate signature but with &quot;unknown&quot; semantic:
I dont like to speculate about it, but whoever implements
any_container&lt;T,any_alloc&gt; and wants to use construct(..)
probably must think about it.
</p>
<p><b>Proposed resolution:</b></p>
<p>
Therefore I think that &quot;new&quot; should be replaced with &quot;::new&quot; in both
cases.
</p>
<hr>
<a name="403"><h3>403.&nbsp;basic_string::swap should not throw exceptions</h3></a><p>
<b>Section:</b>&nbsp;21.3.5.8 <a href="lib-strings.html#lib.string::swap"> [lib.string::swap]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Beman Dawes&nbsp; <b>Date:</b>&nbsp;25 Mar 2003</p>

<p>
std::basic_string, 21.3 <a href="lib-strings.html#lib.basic.string"> [lib.basic.string]</a> paragraph 2 says that
basic_string &quot;conforms to the requirements of a Sequence, as specified
in (23.1.1).&quot; The sequence requirements specified in (23.1.1) to not
include any prohibition on swap members throwing exceptions.
</p>

<p>
Section 23.1 <a href="lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> paragraph 10 does limit conditions under
which exceptions may be thrown, but applies only to &quot;all container
types defined in this clause&quot; and so excludes basic_string::swap
because it is defined elsewhere.
</p>

<p>
Eric Niebler points out that 21.3 <a href="lib-strings.html#lib.basic.string"> [lib.basic.string]</a> paragraph 5 explicitly
permits basic_string::swap to invalidates iterators, which is
disallowed by 23.1 <a href="lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> paragraph 10. Thus the standard would
be contradictory if it were read or extended to read as having
basic_string meet 23.1 <a href="lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> paragraph 10 requirements.
</p>

<p>
Yet several LWG members have expressed the belief that the original
intent was that basic_string::swap should not throw exceptions as
specified by 23.1 <a href="lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> paragraph 10, and that the standard is
unclear on this issue. The complexity of basic_string::swap is
specified as &quot;constant time&quot;, indicating the intent was to avoid
copying (which could cause a bad_alloc or other exception). An
important use of swap is to ensure that exceptions are not thrown in
exception-safe code.
</p>

<p>
Note: There remains long standing concern over whether or not it is
possible to reasonably meet the 23.1 <a href="lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> paragraph 10 swap
requirements when allocators are unequal. The specification of
basic_string::swap exception requirements is in no way intended to
address, prejudice, or otherwise impact that concern.
</p>





<p><b>Proposed resolution:</b></p>
<p>
In 21.3.5.8 <a href="lib-strings.html#lib.string::swap"> [lib.string::swap]</a>, add a throws clause:
</p>

<p>
Throws: Shall not throw exceptions.
</p>
<hr>
<a name="404"><h3>404.&nbsp;May a replacement allocation function be declared inline?</h3></a><p>
<b>Section:</b>&nbsp;17.4.3.4 <a href="lib-intro.html#lib.replacement.functions"> [lib.replacement.functions]</a>, 18.4.1 <a href="lib-support.html#lib.new.delete"> [lib.new.delete]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;24 Apr 2003</p>
<p>
The eight basic dynamic memory allocation functions (single-object
and array versions of ::operator new and ::operator delete, in the
ordinary and nothrow forms) are replaceable.  A C++ program may
provide an alternative definition for any of them, which will be used
in preference to the implementation's definition.  
</p>

<p>
Three different parts of the standard mention requirements on
replacement functions: 17.4.3.4 <a href="lib-intro.html#lib.replacement.functions"> [lib.replacement.functions]</a>, 18.4.1.1 <a href="lib-support.html#lib.new.delete.single"> [lib.new.delete.single]</a>
and 18.4.1.2 <a href="lib-support.html#lib.new.delete.array"> [lib.new.delete.array]</a>, and 3.7.3 <a href="basic.html#basic.stc.dynamic"> [basic.stc.dynamic]</a>.
</p>

<p>None of these three places say whether a replacement function may
  be declared inline.  18.4.1.1 <a href="lib-support.html#lib.new.delete.single"> [lib.new.delete.single]</a> paragraph 2 specifies a
  signature for the replacement function, but that's not enough:
  the <tt>inline</tt> specifier is not part of a function's signature.
  One might also reason from 7.1.2 <a href="dcl.html#dcl.fct.spec"> [dcl.fct.spec]</a> paragraph 2, which
  requires that &quot;an inline function shall be defined in every
  translation unit in which it is used,&quot; but this may not be quite
  specific enough either.  We should either explicitly allow or
  explicitly forbid inline replacement memory allocation
  functions.</p>
<p><b>Proposed resolution:</b></p>
<p>
Add a new sentence to the end of 17.4.3.4 <a href="lib-intro.html#lib.replacement.functions"> [lib.replacement.functions]</a> paragraph 3:
&quot;The program's definitions shall not be specified as <tt>inline</tt>.&quot;
</p>
<p><b>Rationale:</b></p>
<p>
The fact that <tt>inline</tt> isn't mentioned appears to have been
nothing more than an oversight.  Existing implementations do not
permit inline functions as replacement memory allocation functions.
Providing this functionality would be difficult in some cases, and is
believed to be of limited value.
</p>
<p>----- End of document -----</p>
</body>
</html>
