<table>
<tr>
<td align="left">Doc. no.</td>
-<td align="left">J16/01-0032 = WG21 N1318</td>
+<td align="left">J16/01-0053 = WG21 N1338</td>
</tr>
<tr>
<td align="left">Date:</td>
-<td align="left">11 Sep 2001</td>
+<td align="left">09 Nov 2001</td>
</tr>
<tr>
<td align="left">Project:</td>
<td align="left">Matt Austern <austern@research.att.com></td>
</tr>
</table>
-<h1>C++ Standard Library Defect Report List (Revision 19)</h1>
+<h1>C++ Standard Library Defect Report List (Revision 20)</h1>
<p>Reference ISO/IEC IS 14882:1998(E)</p>
<p>Also see:</p>
<ul>
document.</p>
<h2>Revision History</h2>
<ul>
+<li>R20:
+Post-Redmond mailing; reflects actions taken in Redmond. Added
+new issues <a href="lwg-active.html#336">336</a>-<a href="lwg-active.html#350">350</a>, of which issues
+<a href="lwg-active.html#347">347</a>-<a href="lwg-active.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-active.html#284">284</a>, <a href="lwg-active.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-active.html#202">202</a>, <a href="lwg-active.html#226">226</a>, <a href="lwg-active.html#233">233</a>,
+<a href="lwg-active.html#270">270</a>, <a href="lwg-active.html#253">253</a>, <a href="lwg-active.html#254">254</a>, <a href="lwg-active.html#323">323</a>.
+</li>
<li>R19:
Pre-Redmond mailing. Added new issues
<a href="lwg-active.html#323">323</a>-<a href="lwg-active.html#335">335</a>.
</li>
<li>R18:
Post-Copenhagen mailing; reflects actions taken in Copenhagen.
-Added new issues <a href="lwg-
active.html#312">312</a>-<a href="lwg-active.html#317">317</a>, and discussed
-new issues <a href="lwg-
active.html#271">271</a>-<a href="lwg-closed.html#314">314</a>.
+Added new issues <a href="lwg-
defects.html#312">312</a>-<a href="lwg-active.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>
to DR.
Changed status of issues
-<a href="lwg-active.html#49">49</a> <a href="lwg-active.html#109">109</a> <a href="lwg-active.html#117">117</a> <a href="lwg-active.html#182">182</a>
-<a href="lwg-active.html#228">228</a> <a href="lwg-active.html#230">230</a> <a href="lwg-active.html#232">232</a> <a href="lwg-active.html#235">235</a>
-<a href="lwg-active.html#238">238</a> <a href="lwg-active.html#241">241</a> <a href="lwg-active.html#242">242</a> <a href="lwg-active.html#250">250</a>
-<a href="lwg-active.html#259">259</a> <a href="lwg-active.html#264">264</a> <a href="lwg-active.html#266">266</a> <a href="lwg-active.html#267">267</a>
-<a href="lwg-active.html#271">271</a> <a href="lwg-active.html#272">272</a> <a href="lwg-active.html#273">273</a> <a href="lwg-active.html#275">275</a>
-<a href="lwg-active.html#281">281</a> <a href="lwg-active.html#284">284</a> <a href="lwg-active.html#285">285</a> <a href="lwg-active.html#286">286</a>
-<a href="lwg-active.html#288">288</a> <a href="lwg-active.html#292">292</a> <a href="lwg-active.html#295">295</a> <a href="lwg-active.html#297">297</a>
-<a href="lwg-active.html#298">298</a> <a href="lwg-active.html#301">301</a> <a href="lwg-active.html#303">303</a> <a href="lwg-active.html#306">306</a>
-<a href="lwg-active.html#307">307</a> <a href="lwg-active.html#308">308</a> <a href="lwg-active.html#312">312</a>
+<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-active.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-active.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
</li>
<li>R17:
Pre-Copenhagen mailing. Converted issues list to XML. Added proposed
-resolutions for issues <a href="lwg-active.html#49">49</a>, <a href="lwg-active.html#76">76</a>, <a href="lwg-active.html#91">91</a>, <a href="lwg-active.html#235">235</a>, <a href="lwg-active.html#250">250</a>, <a href="lwg-active.html#267">267</a>.
+resolutions for issues <a href="lwg-defects.html#49">49</a>, <a href="lwg-active.html#76">76</a>, <a href="lwg-active.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-active.html#278">278</a>-<a href="lwg-active.html#311">311</a>.
</li>
<li>R16:
</li>
<li>R15:
pre-Toronto mailing. Added issues
-<a href="lwg-active.html#233">233</a>-<a href="lwg-active.html#264">264</a>. Some small HTML formatting
+<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-active.html#228">228</a> to <a href="lwg-active.html#232">232</a>. (00-0019R1/N1242)
+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>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-active.html#91">91</a>, <a href="lwg-active.html#92">92</a>,
-<a href="lwg-
active.html#109">109</a>. Added issues <a href="lwg-closed.html#190">190</a> to
+<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:
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-active.html#109">109</a>
+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:
London meeting, and the exact wording below was accepted at the
Morristown meeting.</p>
<p><b>Proposed resolution:</b></p>
-<p>Change 17.4.2.2 paragraph 2
+<p>Change 17.4.2.2 <a href="lib-intro.html#lib.using.linkage"> [lib.using.linkage]</a> paragraph 2
from:</p>
<blockquote>
pos1, size_type n1, const charT* s) const int compare(size_type pos1, size_type n1, const
charT* s, size_type n2) const; each defined in terms of the corresponding constructor. </p>
<p><b>Proposed resolution:</b></p>
-<p>Replace the compare signature in 21.3
+<p>Replace the compare signature in 21.3 <a href="lib-strings.html#lib.basic.string"> [lib.basic.string]</a>
(at the very end of the basic_string synopsis) which reads:</p>
<blockquote>
size_type n2) const;</tt></p>
</blockquote>
-<p>Replace the portion of 21.3.6.8
+<p>Replace the portion of 21.3.6.8 <a href="lib-strings.html#lib.string::compare"> [lib.string::compare]</a>
paragraphs 5 and 6 which read:</p>
<blockquote>
<hr>
<a name="7"><h3>7. String clause minor problems</h3></a><p>
<b>Section:</b> 21 <a href="lib-strings.html#lib.strings"> [lib.strings]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 15 Dec 1997</p>
-<p>(1) In 21.3.5.4 , the description of template
+<p>(1) In 21.3.5.4 <a href="lib-strings.html#lib.string::insert"> [lib.string::insert]</a>, the description of template
<class InputIterator> insert(iterator, InputIterator,
InputIterator) makes no sense. It refers to a member function that
doesn't exist. It also talks about the return value of a void
charT* in the description. Second, given what it says in RETURNS,
leaving out the final argument will always result in an exception
getting thrown. This is paragraphs 5 and 6 of
-21.3.6.8 </p>
+21.3.6.8 <a href="lib-strings.html#lib.string::compare"> [lib.string::compare]</a>
+</p>
-<p>(6) In table 37, in section 21.1.1 ,
+<p>(6) In table 37, in section 21.1.1 <a href="lib-strings.html#lib.char.traits.require"> [lib.char.traits.require]</a>,
there's a note for X::move(s, p, n). It says "Copies correctly
even where p is in [s, s+n)". This is correct as far as it goes,
but it doesn't go far enough; it should also guarantee that the copy
<p>The intent, I think, is that it should not, but I can't find any
such words anywhere. </p>
<p><b>Proposed resolution:</b></p>
-<p>Add a sentence at the end of 22.1.1.5 ,
+<p>Add a sentence at the end of 22.1.1.5 <a href="lib-locales.html#lib.locale.statics"> [lib.locale.statics]</a>,
paragraph 2: </p>
<blockquote>
<p><b>Proposed resolution:</b></p>
<p>ITEMS 1 AND 2:<br>
<br>
-In the bitset synopsis (23.3.5 ),
+In the bitset synopsis (23.3.5 <a href="lib-containers.html#lib.template.bitset"> [lib.template.bitset]</a>),
replace the member function <br>
<br>
<tt> reference operator[](size_t pos);<br>
<tt> bool operator[](size_t pos) const; <br>
reference operator[](size_t pos); <br>
</tt><br>
-Add the following text at the end of 23.3.5.2 ,
+Add the following text at the end of 23.3.5.2 <a href="lib-containers.html#lib.bitset.members"> [lib.bitset.members]</a>,
immediately after paragraph 45:</p>
<blockquote>
</blockquote>
<p><b>Rationale:</b></p>
<p>The LWG believes Item 3 is not a defect. "Formatted
-input" implies the desired semantics. See 27.6.1.2 .
+input" implies the desired semantics. See 27.6.1.2 <a href="lib-iostreams.html#lib.istream.formatted"> [lib.istream.formatted]</a>.
</p>
<hr>
<a name="13"><h3>13. Eos refuses to die</h3></a><p>
the only one in the whole draft (at least using Acrobat search), so
it's undefined. </p>
<p><b>Proposed resolution:</b></p>
-<p>In 27.6.1.2.3 , replace "eos" with
+<p>In 27.6.1.2.3 <a href="lib-iostreams.html#lib.istream::extractors"> [lib.istream::extractors]</a>, replace "eos" with
"charT()"</p>
<hr>
<a name="14"><h3>14. Locale::combine should be const</h3></a><p>
which was transformed into member "combine". It should have been added at that
time, but the omission was not noticed. </p>
<p><b>Proposed resolution:</b></p>
-<p>In 22.1.1 and also in 22.1.1.3 , add
+<p>In 22.1.1 <a href="lib-locales.html#lib.locale"> [lib.locale]</a> and also in 22.1.1.3 <a href="lib-locales.html#lib.locale.members"> [lib.locale.members]</a>, add
"const" to the declaration of member combine: </p>
<blockquote>
<pre>template <class Facet> locale combine(const locale& other) const; </pre>
<p>locale::name() is described as returning a string that can be passed to a locale
constructor, but there is no matching constructor. </p>
<p><b>Proposed resolution:</b></p>
-<p>In 22.1.1.3 , paragraph 5, replace
+<p>In 22.1.1.3 <a href="lib-locales.html#lib.locale.members"> [lib.locale.members]</a>, paragraph 5, replace
"<tt>locale(name())</tt>" with
"<tt>locale(name().c_str())</tt>".
</p>
<p><b>Proposed resolution:</b></p>
<p>The correct declarations for the overloaded members
<tt>do_narrow</tt> and <tt>do_widen</tt> should be copied
-from 22.2.1.3 .</p>
+from 22.2.1.3 <a href="lib-locales.html#lib.facet.ctype.special"> [lib.facet.ctype.special]</a>.</p>
<hr>
<a name="17"><h3>17. Bad bool parsing</h3></a><p>
<b>Section:</b> 22.2.2.1.2 <a href="lib-locales.html#lib.facet.num.get.virtuals"> [lib.facet.num.get.virtuals]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
when one is a substring of the other. The proposed text below captures the logic of the
code above.</p>
<p><b>Proposed resolution:</b></p>
-<p>In 22.2.2.1.2 , in the first line of paragraph 14,
+<p>In 22.2.2.1.2 <a href="lib-locales.html#lib.facet.num.get.virtuals"> [lib.facet.num.get.virtuals]</a>, in the first line of paragraph 14,
change "&&" to "&".</p>
<p>Then, replace paragraphs 15 and 16 as follows:</p>
members, though it is listed in the class definition and the corresponding
virtual is listed everywhere appropriate. </p>
<p><b>Proposed resolution:</b></p>
-<p>Add at the beginning of 22.2.2.1.1
+<p>Add at the beginning of 22.2.2.1.1 <a href="lib-locales.html#lib.facet.num.get.members"> [lib.facet.num.get.members]</a>
another get member for bool&, copied from the entry in
-22.2.2.1 .</p>
+22.2.2.1 <a href="lib-locales.html#lib.locale.num.get"> [lib.locale.num.get]</a>.</p>
<hr>
<a name="19"><h3>19. "Noconv" definition too vague</h3></a><p>
<b>Section:</b> 22.2.1.5.2 <a href="lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
<p><b>Proposed resolution:</b></p>
<p>
Change the entry for noconv in the table under paragraph 4 in section
-22.2.1.5.2 to read:
+22.2.1.5.2 <a href="lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a> to read:
</p>
<blockquote>
<p>
that it returns a value of type char_type. Here it is erroneously
described as returning a "string_type". </p>
<p><b>Proposed resolution:</b></p>
-<p>In 22.2.3.1.2 , above paragraph 2, change
+<p>In 22.2.3.1.2 <a href="lib-locales.html#lib.facet.numpunct.virtuals"> [lib.facet.numpunct.virtuals]</a>, above paragraph 2, change
"string_type" to "char_type". </p>
<hr>
<a name="21"><h3>21. Codecvt_byname<> instantiations</h3></a><p>
have been omitted. These are necessary to allow users to construct a
locale by name from facets. </p>
<p><b>Proposed resolution:</b></p>
-<p>Add in 22.1.1.1.1 to the table captioned
+<p>Add in 22.1.1.1.1 <a href="lib-locales.html#lib.locale.category"> [lib.locale.category]</a> to the table captioned
"Required instantiations", in the category "ctype"
the lines </p>
reasonable resolutions: 1) status quo 2) fail if fail(), ignore eofbit 3) clear failbit
and eofbit on call to open(). </p>
<p><b>Proposed resolution:</b></p>
-<p>In 27.8.1.7 paragraph 3, <i>and</i> in 27.8.1.10 paragraph 3, under open() effects, add a footnote:
+<p>In 27.8.1.7 <a href="lib-iostreams.html#lib.ifstream.members"> [lib.ifstream.members]</a> paragraph 3, <i>and</i> in 27.8.1.10 <a href="lib-iostreams.html#lib.ofstream.members"> [lib.ofstream.members]</a> paragraph 3, under open() effects, add a footnote:
</p>
<blockquote>
<p>A successful open does not change the error state.</p>
</blockquote>
+<p><b>Rationale:</b></p>
+<p>This may seem surprising to some users, but it's just an instance
+of a general rule: error flags are never cleared by the
+implementation. The only way error flags are are ever cleared is if
+the user explicitly clears them by hand.</p>
+
+<p>The LWG believed that preserving this general rule was
+important enough so that an exception shouldn't be made just for this
+one case. The resolution of this issue clarifies what the LWG
+believes to have been the original intent.</p>
+
<hr>
<a name="24"><h3>24. "do_convert" doesn't exist</h3></a><p>
<b>Section:</b> 22.2.1.5.2 <a href="lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
standard. This is a leftover from an edit, and should be "do_in
and do_out". </p>
<p><b>Proposed resolution:</b></p>
-<p>In 22.2.1.5 , paragraph 3, change
-"do_convert" to "do_in or do_out". Also, in 22.2.1.5.2 , change "do_convert()" to "do_in
+<p>In 22.2.1.5 <a href="lib-locales.html#lib.locale.codecvt"> [lib.locale.codecvt]</a>, paragraph 3, change
+"do_convert" to "do_in or do_out". Also, in 22.2.1.5.2 <a href="lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a>, change "do_convert()" to "do_in
or do_out". </p>
<hr>
<a name="25"><h3>25. String operator<< uses width() value wrong</h3></a><p>
the smaller of os.width() and str.size(), to pad "as described in stage 3"
elsewhere; but this is inconsistent, as this allows no possibility of space for padding. </p>
<p><b>Proposed resolution:</b></p>
-<p>Change 21.3.7.9 paragraph 4 from:<br>
+<p>Change 21.3.7.9 <a href="lib-strings.html#lib.string.io"> [lib.string.io]</a> paragraph 4 from:<br>
<br>
"... where <tt>n</tt> is the smaller of <tt>os.width()</tt> and <tt>str.size()</tt>;
..."<br>
semantics. (E.g. it specifies skipping over the first character in the
sequence without examining it.) </p>
<p><b>Proposed resolution:</b></p>
-<p>Remove the example above from 27.6.1.1.2
+<p>Remove the example above from 27.6.1.1.2 <a href="lib-iostreams.html#lib.istream::sentry"> [lib.istream::sentry]</a>
paragraph 6.</p>
<p><b>Rationale:</b></p>
<p>The originally proposed replacement code for the example was not
"abcde", erasing the range ['b'..'d') would yield an iterator for element 'e',
while 'd' has not been erased. </p>
<p><b>Proposed resolution:</b></p>
-<p>In 21.3.5.5 , paragraph 10, change: </p>
+<p>In 21.3.5.5 <a href="lib-strings.html#lib.string::erase"> [lib.string::erase]</a>, paragraph 10, change: </p>
<blockquote>
<p>Returns: an iterator which points to the element immediately following _last_ prior to
<p>This is intended to copy the value indexed from table()[] into the place identified in
vec[]. </p>
<p><b>Proposed resolution:</b></p>
-<p>Change 22.2.1.3.2 , paragraph 4, to read </p>
+<p>Change 22.2.1.3.2 <a href="lib-locales.html#lib.facet.ctype.char.members"> [lib.facet.ctype.char.members]</a>, paragraph 4, to read </p>
<blockquote>
<p>Effects: The second form, for all *p in the range [low, high), assigns into vec[p-low]
<hr>
<a name="29"><h3>29. Ios_base::init doesn't exist</h3></a><p>
<b>Section:</b> 27.3.1 <a href="lib-iostreams.html#lib.narrow.stream.objects"> [lib.narrow.stream.objects]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
-<p>Sections 27.3.1 and 27.3.2 mention
+<p>Sections 27.3.1 <a href="lib-iostreams.html#lib.narrow.stream.objects"> [lib.narrow.stream.objects]</a> and 27.3.2 <a href="lib-iostreams.html#lib.wide.stream.objects"> [lib.wide.stream.objects]</a> mention
a function ios_base::init, which is not defined. Probably they mean
-basic_ios<>::init, defined in 27.4.4.1 ,
+basic_ios<>::init, defined in 27.4.4.1 <a href="lib-iostreams.html#lib.basic.ios.cons"> [lib.basic.ios.cons]</a>,
paragraph 3. </p>
<p><b>Proposed resolution:</b></p>
<p>[R12: modified to include paragraph 5.]</p>
-<p>In 27.3.1 paragraph 2 and 5, change </p>
+<p>In 27.3.1 <a href="lib-iostreams.html#lib.narrow.stream.objects"> [lib.narrow.stream.objects]</a> paragraph 2 and 5, change </p>
<blockquote>
<p>ios_base::init </p>
<p>basic_ios<char>::init </p>
</blockquote>
-<p>Also, make a similar change in 27.3.2 except it
+<p>Also, make a similar change in 27.3.2 <a href="lib-iostreams.html#lib.wide.stream.objects"> [lib.wide.stream.objects]</a> except it
should read </p>
<blockquote>
<p>Paragraph 2 implies that the C macros LC_CTYPE etc. are defined in <cctype>,
where they are in fact defined elsewhere to appear in <clocale>. </p>
<p><b>Proposed resolution:</b></p>
-<p>In 22.1.1.1.1 , paragraph 2, change
+<p>In 22.1.1.1.1 <a href="lib-locales.html#lib.locale.category"> [lib.locale.category]</a>, paragraph 2, change
"<cctype>" to read "<clocale>". </p>
<hr>
<a name="31"><h3>31. Immutable locale values</h3></a><p>
...". This has caused some confusion, because locale variables
are manifestly assignable. </p>
<p><b>Proposed resolution:</b></p>
-<p>In 22.1.1 replace paragraph 6</p>
+<p>In 22.1.1 <a href="lib-locales.html#lib.locale"> [lib.locale]</a> replace paragraph 6</p>
<blockquote>
<p>An instance of <tt>locale</tt> is immutable; once a facet
<p>It appears that the pbackfail description is wrong. </p>
<p><b>Proposed resolution:</b></p>
-<p>In 27.5.2.4.4 , paragraph 1, change:</p>
+<p>In 27.5.2.4.4 <a href="lib-iostreams.html#lib.streambuf.virt.pback"> [lib.streambuf.virt.pback]</a>, paragraph 1, change:</p>
<blockquote>
<p>"<tt>traits::eq(*gptr(),traits::to_char_type( c))</tt>"</p>
<p>but from_type is not defined. This clearly is intended to be an externT for do_in, or
an internT for do_out. </p>
<p><b>Proposed resolution:</b></p>
-<p>In 22.2.1.5.2 paragraph 4, replace the definition
+<p>In 22.2.1.5.2 <a href="lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a> paragraph 4, replace the definition
in the table for the case of _error_ with </p>
<blockquote>
ctype<charT>, but it has no such members. Note that this is also a problem in
22.2.2.1.2, addressed in (4). </p>
<p><b>Proposed resolution:</b></p>
-<p>In 22.2.2.2.2 , paragraph 19, in the Effects:
+<p>In 22.2.2.2.2 <a href="lib-locales.html#lib.facet.num.put.virtuals"> [lib.facet.num.put.virtuals]</a>, paragraph 19, in the Effects:
clause for member put(...., bool), replace the initialization of the
string_type value s as follows: </p>
<hr>
<a name="35"><h3>35. No manipulator unitbuf in synopsis</h3></a><p>
<b>Section:</b> 27.4 <a href="lib-iostreams.html#lib.iostreams.base"> [lib.iostreams.base]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
-<p>In 27.4.5.1 , we have a definition for a manipulator
+<p>In 27.4.5.1 <a href="lib-iostreams.html#lib.fmtflags.manip"> [lib.fmtflags.manip]</a>, we have a definition for a manipulator
named "unitbuf". Unlike other manipulators, it's not listed
in synopsis. Similarly for "nounitbuf". </p>
<p><b>Proposed resolution:</b></p>
-<p>Add to the synopsis for <ios> in 27.4 , after
+<p>Add to the synopsis for <ios> in 27.4 <a href="lib-iostreams.html#lib.iostreams.base"> [lib.iostreams.base]</a>, after
the entry for "nouppercase", the prototypes: </p>
<blockquote>
<p>This is not idle speculation; at least one implementation was done this way. </p>
<p><b>Proposed resolution:</b></p>
-<p>Add in 27.4.2.5 , in both paragraph 2 and also in
+<p>Add in 27.4.2.5 <a href="lib-iostreams.html#lib.ios.base.storage"> [lib.ios.base.storage]</a>, in both paragraph 2 and also in
paragraph 4, replace the sentence: </p>
<blockquote>
<p>This is not supported by the definition of use_facet<>, and represents semantics
from an old draft. </p>
<p><b>Proposed resolution:</b></p>
-<p>In 22.1.1 , paragraph 4, delete the parenthesized
+<p>In 22.1.1 <a href="lib-locales.html#lib.locale"> [lib.locale]</a>, paragraph 4, delete the parenthesized
expression </p>
<blockquote>
<blockquote>
<p>Requires: <tt>Facet</tt> is a facet class whose definition
- contains the public static member <tt>id</tt> as defined in 22.1.1.1.2 . </p>
+ contains the public static member <tt>id</tt> as defined in 22.1.1.1.2 <a href="lib-locales.html#lib.locale.facet"> [lib.locale.facet]</a>. </p>
</blockquote>
<p><i>[
return(tmp); </pre>
</blockquote>
<p><b>Proposed resolution:</b></p>
-<p>In 24.5.3.4 , delete the three lines of code at the
+<p>In 24.5.3.4 <a href="lib-iterators.html#lib.istreambuf.iterator::op++"> [lib.istreambuf.iterator::op++]</a>, delete the three lines of code at the
end of paragraph 3. </p>
<hr>
<a name="40"><h3>40. Meaningless normative paragraph in examples</h3></a><p>
implementation technique that has lost its referent, and doesn't mean
anything. </p>
<p><b>Proposed resolution:</b></p>
-<p>Delete 22.2.8 paragraph 3 which begins "This
+<p>Delete 22.2.8 <a href="lib-locales.html#lib.facets.examples"> [lib.facets.examples]</a> paragraph 3 which begins "This
initialization/identification system depends...", or (at the
editor's option) replace it with a place-holder to keep the paragraph
numbering the same. </p>
<hr>
<a name="41"><h3>41. Ios_base needs clear(), exceptions()</h3></a><p>
<b>Section:</b> 27.4.2 <a href="lib-iostreams.html#lib.ios.base"> [lib.ios.base]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
-<p>The description of ios_base::iword() and pword() in 27.4.2.4 , say that if they fail, they "set badbit,
+<p>The description of ios_base::iword() and pword() in 27.4.2.4 <a href="lib-iostreams.html#lib.ios.members.static"> [lib.ios.members.static]</a>, say that if they fail, they "set badbit,
which may throw an exception". However, ios_base offers no
interface to set or to test badbit; those interfaces are defined in
basic_ios<>. </p>
<p><b>Proposed resolution:</b></p>
-<p>Change the description in 27.4.2.5 in
+<p>Change the description in 27.4.2.5 <a href="lib-iostreams.html#lib.ios.base.storage"> [lib.ios.base.storage]</a> in
paragraph 2, and also in paragraph 4, as follows. Replace</p>
<blockquote>
and an evident source of confusion, for basic_string<> to have
it, so it might better be removed. </p>
<p><b>Proposed resolution:</b></p>
-<p> In 21.3 , replace the declaration of the copy
+<p> In 21.3 <a href="lib-strings.html#lib.basic.string"> [lib.basic.string]</a>, replace the declaration of the copy
constructor as follows: </p>
<blockquote>
const Allocator& a = Allocator());</pre>
</blockquote>
-<p>In 21.3.1 , replace the copy constructor declaration
+<p>In 21.3.1 <a href="lib-strings.html#lib.string.cons"> [lib.string.cons]</a>, replace the copy constructor declaration
as above. Add to paragraph 5, Effects:</p>
<blockquote>
<p>The LWG considered two other possible resolutions:</p>
-<p>A. In 21.3 , replace the declaration of the copy
+<p>A. In 21.3 <a href="lib-strings.html#lib.basic.string"> [lib.basic.string]</a>, replace the declaration of the copy
constructor as follows:</p>
<blockquote>
size_type n, const Allocator& a); </pre>
</blockquote>
-<p>In 21.3.1 , replace the copy constructor declaration
+<p>In 21.3.1 <a href="lib-strings.html#lib.string.cons"> [lib.string.cons]</a>, replace the copy constructor declaration
as above. Add to paragraph 5, Effects: </p>
<blockquote>
value <tt>str.get_allocator()</tt>. </p>
</blockquote>
-<p>B. In 21.3 , and also in 21.3.1 , replace
+<p>B. In 21.3 <a href="lib-strings.html#lib.basic.string"> [lib.basic.string]</a>, and also in 21.3.1 <a href="lib-strings.html#lib.string.cons"> [lib.string.cons]</a>, replace
the declaration of the copy constructor as follows: </p>
<blockquote>
<b>Section:</b> D.7 <a href="future.html#depr.str.strstreams"> [depr.str.strstreams]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Brendan Kehoe <b>Date:</b> 1 Jun 1998</p>
<p>See lib-6522 and edit-814.</p>
<p><b>Proposed resolution:</b></p>
-<p>Change D.7.1 (since streambuf is a typedef of
+<p>Change D.7.1 <a href="future.html#depr.strstreambuf"> [depr.strstreambuf]</a> (since streambuf is a typedef of
basic_streambuf<char>) from:</p>
<pre> virtual streambuf<char>* setbuf(char* s, streamsize n);</pre>
<pre> virtual streambuf* setbuf(char* s, streamsize n);</pre>
-<p>In D.7.4 insert the semicolon now missing after
+<p>In D.7.4 <a href="future.html#depr.strstream"> [depr.strstream]</a> insert the semicolon now missing after
int_type:</p>
<pre> namespace std {
correct in thinking that paragraphs 2 and 4 just got mixed up by
accident?</p>
<p><b>Proposed resolution:</b></p>
-<p>In 27.4.2.3 swap paragraphs 2 and 4.</p>
+<p>In 27.4.2.3 <a href="lib-iostreams.html#lib.ios.base.locales"> [lib.ios.base.locales]</a> swap paragraphs 2 and 4.</p>
<hr>
<a name="48"><h3>48. Use of non-existent exception constructor</h3></a><p>
<b>Section:</b> 27.4.2.1.1 <a href="lib-iostreams.html#lib.ios::failure"> [lib.ios::failure]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 21 Jun 1998</p>
base class, exception, with exception(msg). Class exception (see
18.6.1) has no such constructor.</p>
<p><b>Proposed resolution:</b></p>
-<p>Replace 27.4.2.1.1 , paragraph 2, with</p>
+<p>Replace 27.4.2.1.1 <a href="lib-iostreams.html#lib.ios::failure"> [lib.ios::failure]</a>, paragraph 2, with</p>
<blockquote>
<p>EFFECTS: Constructs an object of class <tt>failure</tt>.</p>
</blockquote>
<hr>
+<a name="49"><h3>49. Underspecification of ios_base::sync_with_stdio</h3></a><p>
+<b>Section:</b> 27.4.2.4 <a href="lib-iostreams.html#lib.ios.members.static"> [lib.ios.members.static]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 21 Jun 1998</p>
+<p>Two problems</p>
+
+<p>(1) 27.4.2.4 doesn't say what ios_base::sync_with_stdio(f)
+returns. Does it return f, or does it return the previous
+synchronization state? My guess is the latter, but the standard
+doesn't say so.</p>
+
+<p>(2) 27.4.2.4 doesn't say what it means for streams to be
+synchronized with stdio. Again, of course, I can make some
+guesses. (And I'm unhappy about the performance implications of those
+guesses, but that's another matter.)</p>
+<p><b>Proposed resolution:</b></p>
+<p>Change the following sentence in 27.4.2.4 <a href="lib-iostreams.html#lib.ios.members.static"> [lib.ios.members.static]</a>
+returns clause from:</p>
+
+<blockquote>
+ <p>
+<tt>true</tt> if the standard iostream objects (27.3) are
+ synchronized and otherwise returns <tt>false</tt>.</p>
+</blockquote>
+
+<p>to:</p>
+
+<blockquote>
+ <p>
+<tt>true</tt> if the previous state of the standard iostream
+ objects (27.3) was synchronized and otherwise returns
+ <tt>false</tt>.</p>
+</blockquote>
+
+<p>Add the following immediately after 27.4.2.4 <a href="lib-iostreams.html#lib.ios.members.static"> [lib.ios.members.static]</a>,
+paragraph 2:</p>
+
+<blockquote>
+<p>When a standard iostream object str is <i>synchronized</i> with a
+standard stdio stream f, the effect of inserting a character c by</p>
+<pre>
+ fputc(f, c);
+</pre>
+
+<p>is the same as the effect of</p>
+<pre>
+ str.rdbuf()->sputc(c);
+</pre>
+
+<p>for any sequence of characters; the effect of extracting a
+character c by</p>
+<pre>
+ c = fgetc(f);
+</pre>
+
+<p>is the same as the effect of:</p>
+<pre>
+ c = str.rdbuf()->sbumpc(c);
+</pre>
+
+<p>for any sequences of characters; and the effect of pushing
+back a character c by</p>
+<pre>
+ ungetc(c, f);
+</pre>
+
+<p>is the same as the effect of</p>
+<pre>
+ str.rdbuf()->sputbackc(c);
+</pre>
+
+<p>for any sequence of characters. [<i>Footnote</i>: This implies
+that operations on a standard iostream object can be mixed arbitrarily
+with operations on the corresponding stdio stream. In practical
+terms, synchronization usually means that a standard iostream object
+and a standard stdio object share a buffer. <i>--End Footnote</i>]</p>
+</blockquote>
+
+<p><i>[pre-Copenhagen: PJP and Matt contributed the definition
+of "synchronization"]</i></p>
+
+<p><i>[post-Copenhagen: proposed resolution was revised slightly:
+text was added in the non-normative footnote to say that operations
+on the two streams can be mixed arbitrarily.]</i></p>
+<hr>
<a name="50"><h3>50. Copy constructor and assignment operator of ios_base</h3></a><p>
<b>Section:</b> 27.4.2 <a href="lib-iostreams.html#lib.ios.base"> [lib.ios.base]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 21 Jun 1998</p>
<p>As written, ios_base has a copy constructor and an assignment
semantics (e.g. what happens to the iarray and parray stuff).
</p>
<p><b>Proposed resolution:</b></p>
-<p>In 27.4.2 , class ios_base, specify the copy
+<p>In 27.4.2 <a href="lib-iostreams.html#lib.ios.base"> [lib.ios.base]</a>, class ios_base, specify the copy
constructor and operator= members as being private.</p>
<p><b>Rationale:</b></p>
<p>The LWG believes the difficulty of specifying correct semantics
<hr>
<a name="52"><h3>52. Small I/O problems</h3></a><p>
<b>Section:</b> 27.4.3.2 <a href="lib-iostreams.html#lib.fpos.operations"> [lib.fpos.operations]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 23 Jun 1998</p>
-<p>First, 27.4.4.1 , table 89. This is pretty obvious:
+<p>First, 27.4.4.1 <a href="lib-iostreams.html#lib.basic.ios.cons"> [lib.basic.ios.cons]</a>, table 89. This is pretty obvious:
it should be titled "basic_ios<>() effects", not
"ios_base() effects". </p>
<p>[The second item is a duplicate; see issue <a href="lwg-closed.html#6">6</a> for
resolution.]</p>
-<p>Second, 27.4.3.2 table 88 . There are a couple
+<p>Second, 27.4.3.2 <a href="lib-iostreams.html#lib.fpos.operations"> [lib.fpos.operations]</a> table 88 . There are a couple
different things wrong with it, some of which I've already discussed
with Jerry, but the most obvious mechanical sort of error is that it
uses expressions like P(i) and p(i), without ever defining what sort
anything meaningful except on platforms, like Unix, where genuine
arithmetic is possible.) </p>
<p><b>Proposed resolution:</b></p>
-<p>Change 27.4.4.1 table 89 title from
+<p>Change 27.4.4.1 <a href="lib-iostreams.html#lib.basic.ios.cons"> [lib.basic.ios.cons]</a> table 89 title from
"ios_base() effects" to "basic_ios<>()
effects". </p>
<hr>
The important question is whether basic_ios::~basic_ios() destroys
rdbuf().</p>
<p><b>Proposed resolution:</b></p>
-<p>Add after 27.4.4.1 paragraph 2:</p>
+<p>Add after 27.4.4.1 <a href="lib-iostreams.html#lib.basic.ios.cons"> [lib.basic.ios.cons]</a> paragraph 2:</p>
<blockquote>
<p><tt>virtual ~basic_ios();</tt></p>
<p><b>Rationale:</b></p>
<p>The LWG reviewed the additional question of whether or not
<tt>rdbuf(0)</tt> may set <tt>badbit</tt>. The answer is
-clearly yes; it may be set via <tt>clear()</tt>. See 27.4.4.2 , paragraph 6. This issue was reviewed at length
+clearly yes; it may be set via <tt>clear()</tt>. See 27.4.4.2 <a href="lib-iostreams.html#lib.basic.ios.members"> [lib.basic.ios.members]</a>, paragraph 6. This issue was reviewed at length
by the LWG, which removed from the original proposed resolution a
footnote which incorrectly said "<tt>rdbuf(0)</tt> does not set
<tt>badbit</tt>".</p>
assumption is that it does nothing, but the standard should say so
explicitly. </p>
<p><b>Proposed resolution:</b></p>
-<p>Add after 27.5.2.1 paragraph 2:</p>
+<p>Add after 27.5.2.1 <a href="lib-iostreams.html#lib.streambuf.cons"> [lib.streambuf.cons]</a> paragraph 2:</p>
<blockquote>
<p><tt>virtual ~basic_streambuf();</tt></p>
stream position" should not be changed:</p>
<blockquote>
- <p>27.7.1.3 , paragraph 14<br>
- 27.8.1.4 , paragraph 14<br>
- D.7.1.3 , paragraph 17
- <a href="lib-iostreams.html#lib.stringbuf.virtuals"> [lib.stringbuf.virtuals]</a>
-</p>
+ <p>27.7.1.3 <a href="lib-iostreams.html#lib.stringbuf.virtuals"> [lib.stringbuf.virtuals]</a>, paragraph 14<br>
+ 27.8.1.4 <a href="lib-iostreams.html#lib.filebuf.virtuals"> [lib.filebuf.virtuals]</a>, paragraph 14<br>
+ D.7.1.3 <a href="future.html#depr.strstreambuf.virtuals"> [depr.strstreambuf.virtuals]</a>, paragraph 17
+ </p>
</blockquote>
<p><b>Proposed resolution:</b></p>
-<p>In 27.5.2.4.2 , paragraph 4, change "Returns an
+<p>In 27.5.2.4.2 <a href="lib-iostreams.html#lib.streambuf.virt.buffer"> [lib.streambuf.virt.buffer]</a>, paragraph 4, change "Returns an
object of class pos_type that stores an invalid stream position
(_lib.iostreams.definitions_)" to "Returns
<tt>pos_type(off_type(-1))</tt>".
</p>
-<p>In 27.5.2.4.2 , paragraph 6, change "Returns
+<p>In 27.5.2.4.2 <a href="lib-iostreams.html#lib.streambuf.virt.buffer"> [lib.streambuf.virt.buffer]</a>, paragraph 6, change "Returns
an object of class pos_type that stores an invalid stream
position" to "Returns <tt>pos_type(off_type(-1))</tt>".</p>
-<p>In 27.7.1.3 , paragraph 13, change "the object
+<p>In 27.7.1.3 <a href="lib-iostreams.html#lib.stringbuf.virtuals"> [lib.stringbuf.virtuals]</a>, paragraph 13, change "the object
stores an invalid stream position" to "the return value is
<tt>pos_type(off_type(-1))</tt>". </p>
-<p>In 27.8.1.4 , paragraph 13, change "returns an
+<p>In 27.8.1.4 <a href="lib-iostreams.html#lib.filebuf.virtuals"> [lib.filebuf.virtuals]</a>, paragraph 13, change "returns an
invalid stream position (27.4.3)" to "returns
<tt>pos_type(off_type(-1))</tt>" </p>
-<p>In 27.8.1.4 , paragraph 15, change "Otherwise
+<p>In 27.8.1.4 <a href="lib-iostreams.html#lib.filebuf.virtuals"> [lib.filebuf.virtuals]</a>, paragraph 15, change "Otherwise
returns an invalid stream position (_lib.iostreams.definitions_)"
to "Otherwise returns <tt>pos_type(off_type(-1))</tt>"
</p>
-<p>In D.7.1.3 , paragraph 15, change "the object
+<p>In D.7.1.3 <a href="future.html#depr.strstreambuf.virtuals"> [depr.strstreambuf.virtuals]</a>, paragraph 15, change "the object
stores an invalid stream position" to "the return value is
<tt>pos_type(off_type(-1))</tt>" </p>
-<p>In D.7.1.3 , paragraph 18, change "the object
+<p>In D.7.1.3 <a href="future.html#depr.strstreambuf.virtuals"> [depr.strstreambuf.virtuals]</a>, paragraph 18, change "the object
stores an invalid stream position" to "the return value is
<tt>pos_type(off_type(-1))</tt>"</p>
<hr>
return type is streamsize. </p>
<p><b>Proposed resolution:</b></p>
<p>Change <tt>showmanyc</tt>'s return type in the
-27.5.2 class summary to <tt>streamsize</tt>.</p>
+27.5.2 <a href="lib-iostreams.html#lib.streambuf"> [lib.streambuf]</a> class summary to <tt>streamsize</tt>.</p>
<hr>
<a name="57"><h3>57. Mistake in char_traits</h3></a><p>
<b>Section:</b> 21.1.3.2 <a href="lib-strings.html#lib.char.traits.specializations.wchar.t"> [lib.char.traits.specializations.wchar.t]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 1 Jul 1998</p>
char_traits<char>::state_type and
char_traits<wchar_t>::state_type must both be mbstate_t. </p>
<p><b>Proposed resolution:</b></p>
-<p>Remove the sentence in 21.1.3.2 paragraph 3 which
+<p>Remove the sentence in 21.1.3.2 <a href="lib-strings.html#lib.char.traits.specializations.wchar.t"> [lib.char.traits.specializations.wchar.t]</a> paragraph 3 which
begins "The types streampos and wstreampos may be
different..." . </p>
<hr>
<p>(The "classic" AT&T implementation used the
former interpretation.)</p>
<p><b>Proposed resolution:</b></p>
-<p>Change 27.5.2.3.1 paragraph 4 gbump effects from:</p>
+<p>Change 27.5.2.3.1 <a href="lib-iostreams.html#lib.streambuf.get.area"> [lib.streambuf.get.area]</a> paragraph 4 gbump effects from:</p>
<blockquote>
<p>Effects: Advances the next pointer for the input sequence by n.</p>
<p>Effects: Adds <tt>n</tt> to the next pointer for the input sequence.</p>
</blockquote>
-<p>Make the same change to 27.5.2.3.2 paragraph 4 pbump
+<p>Make the same change to 27.5.2.3.2 <a href="lib-iostreams.html#lib.streambuf.put.area"> [lib.streambuf.put.area]</a> paragraph 4 pbump
effects.</p>
<hr>
<a name="60"><h3>60. What is a formatted input function?</h3></a><p>
apply to them. </p>
<p>Additional comments from Dietmar Kühl: It appears to be somewhat
-nonsensical to consider the functions defined in 27.6.1.2.3 paragraphs 1 to 5 to be "Formatted input
+nonsensical to consider the functions defined in 27.6.1.2.3 <a href="lib-iostreams.html#lib.istream::extractors"> [lib.istream::extractors]</a> paragraphs 1 to 5 to be "Formatted input
function" but since these functions are defined in a section
labeled "Formatted input functions" it is unclear to me
whether these operators are considered formatted input functions which
-have to conform to the "common requirements" from 27.6.1.2.1 : If this is the case, all manipulators, not
+have to conform to the "common requirements" from 27.6.1.2.1 <a href="lib-iostreams.html#lib.istream.formatted.reqmts"> [lib.istream.formatted.reqmts]</a>: If this is the case, all manipulators, not
just <tt>ws</tt>, would skip whitespace unless <tt>noskipws</tt> is
set (... but setting <tt>noskipws</tt> using the manipulator syntax
would also skip whitespace :-)</p> <p>It is not clear which functions
are to be considered unformatted input functions. As written, it seems
-that all functions in 27.6.1.3 are unformatted input
+that all functions in 27.6.1.3 <a href="lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a> are unformatted input
functions. However, it does not really make much sense to construct a
sentry object for <tt>gcount()</tt>, <tt>sync()</tt>, ... Also it is
unclear what happens to the <tt>gcount()</tt> if
<p>That looks suspicious, because traits::eof() is of type
traits::int_type while the return type of sync() is int. </p>
<p><b>Proposed resolution:</b></p>
-<p>In 27.6.1.3 , paragraph 36, change "returns
+<p>In 27.6.1.3 <a href="lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a>, paragraph 36, change "returns
<tt>traits::eof()</tt>" to "returns <tt>-1</tt>".
</p>
<hr>
different ways, depending on whether the second sentence is read as an
elaboration of the first. </p>
<p><b>Proposed resolution:</b></p>
-<p>Replace 27.6.1.2.3 , paragraph 13, which begins
+<p>Replace 27.6.1.2.3 <a href="lib-iostreams.html#lib.istream::extractors"> [lib.istream::extractors]</a>, paragraph 13, which begins
"If the function inserts no characters ..." with:</p>
<blockquote>
cut-and-paste from basic_streambuf. There are no classes derived from
strstreambuf. </p>
<p><b>Proposed resolution:</b></p>
-<p>D.7.1.3 , paragraph 19, replace the setbuf effects
+<p>D.7.1.3 <a href="future.html#depr.strstreambuf.virtuals"> [depr.strstreambuf.virtuals]</a>, paragraph 19, replace the setbuf effects
clause which currently says "Performs an operation that is
defined separately for each class derived from strstreambuf"
-with:<a href="future.html#depr.strstreambuf.virtuals"> [depr.strstreambuf.virtuals]</a>
-</p>
+with:</p>
<blockquote>
<p>
extraction doesn't make any sense. It was supposed to be the line that
said a null is stored.</p>
<p><b>Proposed resolution:</b></p>
-<p>27.6.1.2.3 , paragraph 7, change the last list
-item from:<a href="lib-iostreams.html#lib.istream::extractors"> [lib.istream::extractors]</a>
-</p>
+<p>27.6.1.2.3 <a href="lib-iostreams.html#lib.istream::extractors"> [lib.istream::extractors]</a>, paragraph 7, change the last list
+item from:</p>
<blockquote>
A null byte (<tt>charT()</tt>) in the next position, which may be
that question is clearly "no," as it would rule out
debugging implementations)</p>
<p><b>Proposed resolution:</b></p>
-<p>Add the following text to the end of 23.2.4 ,
+<p>Add the following text to the end of 23.2.4 <a href="lib-containers.html#lib.vector"> [lib.vector]</a>,
paragraph 1. </p>
<blockquote>
<ul>
<li>An operational definition similar to the above proposed resolution is
- already used for valarray (26.3.2.3 ).</li>
+ already used for valarray (26.3.2.3 <a href="lib-numerics.html#lib.valarray.access"> [lib.valarray.access]</a>).</li>
<li>There is no need to explicitly consider a user-defined operator&
- because elements must be copyconstructible (23.1 para 3)
- and copyconstructible (20.1.3 ) specifies
+ because elements must be copyconstructible (23.1 <a href="lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> para 3)
+ and copyconstructible (20.1.3 <a href="lib-utilities.html#lib.copyconstructible"> [lib.copyconstructible]</a>) specifies
requirements for operator&.</li>
<li>There is no issue of one-past-the-end because of language rules.</li>
</ul>
<p>uncaught_exception() is called in exception handling contexts where
exception safety is very important.</p>
<p><b>Proposed resolution:</b></p>
-<p>In 15.5.3 , paragraph 1, 18.6 , and 18.6.4 , add "throw()" to uncaught_exception().</p>
+<p>In 15.5.3 <a href="except.html#except.uncaught"> [except.uncaught]</a>, paragraph 1, 18.6 <a href="lib-support.html#lib.support.exception"> [lib.support.exception]</a>, and 18.6.4 <a href="lib-support.html#lib.uncaught"> [lib.uncaught]</a>, add "throw()" to uncaught_exception().</p>
<hr>
<a name="71"><h3>71. Do_get_monthname synopsis missing argument</h3></a><p>
<b>Section:</b> 22.2.5.1 <a href="lib-locales.html#lib.locale.time.get"> [lib.locale.time.get]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 13 Aug 1998</p>
<p>The locale facet member <tt>time_get<>::do_get_monthname</tt>
-is described in 22.2.5.1.2 with five arguments,
+is described in 22.2.5.1.2 <a href="lib-locales.html#lib.locale.time.get.virtuals"> [lib.locale.time.get.virtuals]</a> with five arguments,
consistent with do_get_weekday and with its specified use by member
get_monthname. However, in the synopsis, it is specified instead with
four arguments. The missing argument is the "end" iterator
value.</p>
<p><b>Proposed resolution:</b></p>
-<p>In 22.2.5.1 , add an "end" argument to
+<p>In 22.2.5.1 <a href="lib-locales.html#lib.locale.time.get"> [lib.locale.time.get]</a>, add an "end" argument to
the declaration of member do_monthname as follows:</p>
<pre> virtual iter_type do_get_monthname(iter_type s, iter_type end, ios_base&,
clause (22.2.1.5.2, paragraph 11) is garbled. It has unbalanced
parentheses and a spurious <b>n</b>.</p>
<p><b>Proposed resolution:</b></p>
-<p>Replace 22.2.1.5.2 paragraph 11 with the
+<p>Replace 22.2.1.5.2 <a href="lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a> paragraph 11 with the
following:</p>
<blockquote>
then we must also add text saying how <tt>do_length</tt> changes its
<tt>stateT</tt> argument. </p>
<p><b>Proposed resolution:</b></p>
-<p>In 22.2.1.5 , and also in 22.2.1.6 ,
+<p>In 22.2.1.5 <a href="lib-locales.html#lib.locale.codecvt"> [lib.locale.codecvt]</a>, and also in 22.2.1.6 <a href="lib-locales.html#lib.locale.codecvt.byname"> [lib.locale.codecvt.byname]</a>,
change the <tt>stateT</tt> argument type on both member
<tt>length()</tt> and member <tt>do_length()</tt> from </p>
<p><tt>stateT&</tt></p>
</blockquote>
-<p>In 22.2.1.5.2 , add to the definition for member
+<p>In 22.2.1.5.2 <a href="lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a>, add to the definition for member
<tt>do_length</tt> a paragraph:</p>
<blockquote>
<b>Section:</b> 27.4.2 <a href="lib-iostreams.html#lib.ios.base"> [lib.ios.base]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Nico Josuttis <b>Date:</b> 29 Sep 1998</p>
<p>typo: event_call_back should be event_callback </p>
<p><b>Proposed resolution:</b></p>
-<p>In the 27.4.2 synopsis change
+<p>In the 27.4.2 <a href="lib-iostreams.html#lib.ios.base"> [lib.ios.base]</a> synopsis change
"event_call_back" to "event_callback". </p>
<hr>
<a name="79"><h3>79. Inconsistent declaration of polar()</h3></a><p>
<b>Section:</b> 26.2.1 <a href="lib-numerics.html#lib.complex.synopsis"> [lib.complex.synopsis]</a>, 26.2.7 <a href="lib-numerics.html#lib.complex.value.ops"> [lib.complex.value.ops]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Nico Josuttis <b>Date:</b> 29 Sep 1998</p>
-<p>In 26.2.1 polar is declared as follows:</p>
+<p>In 26.2.1 <a href="lib-numerics.html#lib.complex.synopsis"> [lib.complex.synopsis]</a> polar is declared as follows:</p>
<pre> template<class T> complex<T> polar(const T&, const T&); </pre>
-<p>In 26.2.7 it is declared as follows:</p>
+<p>In 26.2.7 <a href="lib-numerics.html#lib.complex.value.ops"> [lib.complex.value.ops]</a> it is declared as follows:</p>
<pre> template<class T> complex<T> polar(const T& rho, const T& theta = 0); </pre>
<p>Thus whether the second parameter is optional is not clear. </p>
<p><b>Proposed resolution:</b></p>
-<p>In 26.2.1 change:</p>
+<p>In 26.2.1 <a href="lib-numerics.html#lib.complex.synopsis"> [lib.complex.synopsis]</a> change:</p>
<pre> template<class T> complex<T> polar(const T&, const T&);</pre>
<p>to:</p>
size exceeds max_size() but not npos, then? It seems the standard
lacks some clarifications here.</p>
<p><b>Proposed resolution:</b></p>
-<p>After 21.3 paragraph 4 ("The functions
+<p>After 21.3 <a href="lib-strings.html#lib.basic.string"> [lib.basic.string]</a> paragraph 4 ("The functions
described in this clause...") add a new paragraph:</p>
<blockquote>
according to the other constructors if the numbers of characters in
the range equals npos (or exceeds max_size(), see above). </p>
<p><b>Proposed resolution:</b></p>
-<p>In 21.3.1 , Strike throws paragraphs for
+<p>In 21.3.1 <a href="lib-strings.html#lib.string.cons"> [lib.string.cons]</a>, Strike throws paragraphs for
constructors which say "Throws: length_error if n ==
npos."</p>
<p><b>Rationale:</b></p>
<p>Here <tt>getloc()</tt> has to be replaced by <tt>is.getloc()</tt>. </p>
<p><b>Proposed resolution:</b></p>
-<p>In 21.3.7.9 paragraph 1 Effects clause replace:</p>
+<p>In 21.3.7.9 <a href="lib-strings.html#lib.string.io"> [lib.string.io]</a> paragraph 1 Effects clause replace:</p>
<blockquote>
<p>
<p><tt>typedef implementation defined iterator;<br>
// See _lib.container.requirements_</tt></p>
-<p>23.1 actually requires that iterator type pointing
+<p>23.1 <a href="lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> actually requires that iterator type pointing
to T (table 65). Disallowing user modification of keys by changing the
standard to require an iterator for associative container to be the
same as const_iterator would be overkill since that will unnecessarily
easily without either redesigning the class (using mutable on fields
that have nothing to do with ordering), or using const_cast, which
defeats requiring iterator to be const_iterator. The proposed solution
-goes in line with trusting user knows what he is doing. <a href="lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a>
-</p>
+goes in line with trusting user knows what he is doing. </p>
<p>
<b>Other Options Evaluated:</b> </p>
-<p>Option A. In 23.1.2 , paragraph 2, after
+<p>Option A. In 23.1.2 <a href="lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a>, paragraph 2, after
first sentence, and before "In addition,...", add one line:
</p>
<p>Modification of keys shall not change their strict weak ordering. </p>
</blockquote>
-<p>Option B. Add three new sentences to 23.1.2 :</p>
+<p>Option B. Add three new sentences to 23.1.2 <a href="lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a>:</p>
<blockquote>
<p>At the end of paragraph 5: "Keys in an associative container
type."</p>
</blockquote>
-<p>Option C. To 23.1.2 , paragraph 3, which
+<p>Option C. To 23.1.2 <a href="lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a>, paragraph 3, which
currently reads:</p>
<blockquote>
different than it was the previous time k2 was in the container.]</p>
</blockquote>
<p><b>Proposed resolution:</b></p>
-<p>Add the following to 23.1.2 at
+<p>Add the following to 23.1.2 <a href="lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a> at
the indicated location:</p>
<blockquote>
with exception safety of exception handling: some exceptions should
not throw bad_alloc.</p>
<p><b>Proposed resolution:</b></p>
-<p>Add to 18.6.1 paragraph 9 (exception::what notes
+<p>Add to 18.6.1 <a href="lib-support.html#lib.exception"> [lib.exception]</a> paragraph 9 (exception::what notes
clause) the sentence:</p>
<blockquote>
returned by <tt>what()</tt>.
</p>
<hr>
+<a name="109"><h3>109. Missing binders for non-const sequence elements</h3></a><p>
+<b>Section:</b> 20.3.6 <a href="lib-utilities.html#lib.binders"> [lib.binders]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Bjarne Stroustrup <b>Date:</b> 7 Oct 1998</p>
+
+<p>There are no versions of binders that apply to non-const elements
+of a sequence. This makes examples like for_each() using bind2nd() on
+page 521 of "The C++ Programming Language (3rd)"
+non-conforming. Suitable versions of the binders need to be added.</p>
+
+<p>Further discussion from Nico:</p>
+
+<p>What is probably meant here is shown in the following example:</p>
+
+<pre>class Elem {
+ public:
+ void print (int i) const { }
+ void modify (int i) { }
+}; </pre>
+<pre>int main()
+{
+ vector<Elem> coll(2);
+ for_each (coll.begin(), coll.end(), bind2nd(mem_fun_ref(&Elem::print),42)); // OK
+ for_each (coll.begin(), coll.end(), bind2nd(mem_fun_ref(&Elem::modify),42)); // ERROR
+}</pre>
+
+<p>The error results from the fact that bind2nd() passes its first
+argument (the argument of the sequence) as constant reference. See the
+following typical implementation:</p>
+
+<blockquote>
+ <pre>template <class Operation>
+class binder2nd
+ : public unary_function<typename Operation::first_argument_type,
+ typename Operation::result_type> {
+protected:
+ Operation op;
+ typename Operation::second_argument_type value;
+public:
+ binder2nd(const Operation& o,
+ const typename Operation::second_argument_type& v)
+ : op(o), value(v) {} </pre>
+ <pre> typename Operation::result_type
+ operator()(const typename Operation::first_argument_type& x) const {
+ return op(x, value);
+ }
+};</pre>
+</blockquote>
+
+<p>The solution is to overload operator () of bind2nd for non-constant arguments:</p>
+
+<blockquote>
+ <pre>template <class Operation>
+class binder2nd
+ : public unary_function<typename Operation::first_argument_type,
+ typename Operation::result_type> {
+protected:
+ Operation op;
+ typename Operation::second_argument_type value;
+public:
+ binder2nd(const Operation& o,
+ const typename Operation::second_argument_type& v)
+ : op(o), value(v) {} </pre>
+ <pre> typename Operation::result_type
+ operator()(const typename Operation::first_argument_type& x) const {
+ return op(x, value);
+ }
+ typename Operation::result_type
+ operator()(typename Operation::first_argument_type& x) const {
+ return op(x, value);
+ }
+};</pre>
+</blockquote>
+<p><b>Proposed resolution:</b></p>
+
+<p>
+<b>Howard believes there is a flaw</b> in this resolution.
+See c++std-lib-9127. We may need to reopen this issue.</p>
+
+<p>In 20.3.6.1 <a href="lib-utilities.html#lib.binder.1st"> [lib.binder.1st]</a> in the declaration of binder1st after:</p>
+<blockquote>
+ <p><tt>typename Operation::result_type<br>
+ operator()(const typename Operation::second_argument_type& x) const;</tt></p>
+</blockquote>
+<p>insert:</p>
+<blockquote>
+ <p><tt>typename Operation::result_type<br>
+ operator()(typename Operation::second_argument_type& x) const;</tt></p>
+</blockquote>
+<p>In 20.3.6.3 <a href="lib-utilities.html#lib.binder.2nd"> [lib.binder.2nd]</a> in the declaration of binder2nd after:</p>
+<blockquote>
+ <p><tt>typename Operation::result_type<br>
+ operator()(const typename Operation::first_argument_type& x) const;</tt></p>
+</blockquote>
+<p>insert:</p>
+<blockquote>
+ <p><tt>typename Operation::result_type<br>
+ operator()(typename Operation::first_argument_type& x) const;</tt></p>
+</blockquote>
+
+<p><i>[Kona: The LWG discussed this at some length.It was agreed that
+this is a mistake in the design, but there was no consensus on whether
+it was a defect in the Standard. Straw vote: NAD - 5. Accept
+proposed resolution - 3. Leave open - 6.]</i></p>
+
+<p><i>[Copenhagen: It was generally agreed that this was a defect.
+Strap poll: NAD - 0. Accept proposed resolution - 10.
+Leave open - 1.]</i></p>
+
+<hr>
<a name="110"><h3>110. istreambuf_iterator::equal not const</h3></a><p>
<b>Section:</b> 24.5.3 <a href="lib-iterators.html#lib.istreambuf.iterator"> [lib.istreambuf.iterator]</a>, 24.5.3.5 <a href="lib-iterators.html#lib.istreambuf.iterator::equal"> [lib.istreambuf.iterator::equal]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 15 Oct 1998</p>
<p>Member istreambuf_iterator<>::equal is not declared
-"const", yet 24.5.3.6 says that operator==,
+"const", yet 24.5.3.6 <a href="lib-iterators.html#lib.istreambuf.iterator::op=="> [lib.istreambuf.iterator::op==]</a> says that operator==,
which is const, calls it. This is contradictory. </p>
<p><b>Proposed resolution:</b></p>
-<p>In 24.5.3 and also in 24.5.3.5 ,
+<p>In 24.5.3 <a href="lib-iterators.html#lib.istreambuf.iterator"> [lib.istreambuf.iterator]</a> and also in 24.5.3.5 <a href="lib-iterators.html#lib.istreambuf.iterator::equal"> [lib.istreambuf.iterator::equal]</a>,
replace:</p>
<blockquote>
reads "<i>s</i> is not null". However, <i>s</i> is a
reference, and references can't be null. </p>
<p><b>Proposed resolution:</b></p>
-<p>In 24.5.4.1 :</p>
+<p>In 24.5.4.1 <a href="lib-iterators.html#lib.ostreambuf.iter.cons"> [lib.ostreambuf.iter.cons]</a>:</p>
<p>Move the current paragraph 1, which reads "Requires: s is not
null.", from the first constructor to the second constructor.</p>
likely to fail.</p>
<p><b>Proposed resolution:</b></p>
<p>Replace the <u> first line of code</u> in the example in
-18.4.1.3 with:
+18.4.1.3 <a href="lib-support.html#lib.new.delete.placement"> [lib.new.delete.placement]</a> with:
</p>
<blockquote>
should be "If mode&app==app", or "mode&app!=0", meaning that
the append bit is set.</p>
<p><b>Proposed resolution:</b></p>
-<p>In D.7.3.1 paragraph 2 and D.7.4.1
+<p>In D.7.3.1 <a href="future.html#depr.ostrstream.cons"> [depr.ostrstream.cons]</a> paragraph 2 and D.7.4.1 <a href="future.html#depr.strstream.cons"> [depr.strstream.cons]</a>
paragraph 2, change the first condition to <tt>(mode&app)==0</tt>
and the second condition to <tt>(mode&app)!=0</tt>.</p>
<hr>
+<a name="117"><h3>117. <tt>basic_ostream</tt> uses nonexistent <tt>num_put</tt> member functions</h3></a><p>
+<b>Section:</b> 27.6.2.5.2 <a href="lib-iostreams.html#lib.ostream.inserters.arithmetic"> [lib.ostream.inserters.arithmetic]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 20 Nov 1998</p>
+<p>The <b>effects</b> clause for numeric inserters says that
+insertion of a value <tt>x</tt>, whose type is either <tt>bool</tt>,
+<tt>short</tt>, <tt>unsigned short</tt>, <tt>int</tt>, <tt>unsigned
+int</tt>, <tt>long</tt>, <tt>unsigned long</tt>, <tt>float</tt>,
+<tt>double</tt>, <tt>long double</tt>, or <tt>const void*</tt>, is
+delegated to <tt>num_put</tt>, and that insertion is performed as if
+through the following code fragment: </p>
+
+<pre>bool failed = use_facet<
+ num_put<charT,ostreambuf_iterator<charT,traits> >
+ >(getloc()).put(*this, *this, fill(), val). failed();</pre>
+
+<p>This doesn't work, because <tt>num_put<></tt>::put is only
+overloaded for the types <tt>bool</tt>, <tt>long</tt>, <tt>unsigned
+long</tt>, <tt>double</tt>, <tt>long double</tt>, and <tt>const
+void*</tt>. That is, the code fragment in the standard is incorrect
+(it is diagnosed as ambiguous at compile time) for the types
+<tt>short</tt>, <tt>unsigned short</tt>, <tt>int</tt>, <tt>unsigned
+int</tt>, and <tt>float</tt>. </p>
+
+<p>We must either add new member functions to <tt>num_put</tt>, or
+else change the description in <tt>ostream</tt> so that it only calls
+functions that are actually there. I prefer the latter. </p>
+<p><b>Proposed resolution:</b></p>
+<p>Replace 27.6.2.5.2, paragraph 1 with the following: </p>
+
+<blockquote>
+<p>
+The classes num_get<> and num_put<> handle locale­dependent numeric
+formatting and parsing. These inserter functions use the imbued
+locale value to perform numeric formatting. When val is of type bool,
+long, unsigned long, double, long double, or const void*, the
+formatting conversion occurs as if it performed the following code
+fragment:
+</p>
+
+<pre>
+bool failed = use_facet<
+ num_put<charT,ostreambuf_iterator<charT,traits> >
+ >(getloc()).put(*this, *this, fill(), val). failed();
+</pre>
+
+<p>
+When val is of type short the formatting conversion occurs as if it
+performed the following code fragment:
+</p>
+
+<pre>
+ios_base::fmtflags baseflags = ios_base::flags() & ios_base::basefield;
+bool failed = use_facet<
+ num_put<charT,ostreambuf_iterator<charT,traits> >
+ >(getloc()).put(*this, *this, fill(),
+ baseflags == ios_base::oct || baseflags == ios_base::hex
+ ? static_cast<long>(static_cast<unsigned short>(val))
+ : static_cast<long>(val)). failed();
+</pre>
+
+<p>
+When val is of type int the formatting conversion occurs as if it performed
+the following code fragment:
+</p>
+
+<pre>
+ios_base::fmtflags baseflags = ios_base::flags() & ios_base::basefield;
+bool failed = use_facet<
+ num_put<charT,ostreambuf_iterator<charT,traits> >
+ >(getloc()).put(*this, *this, fill(),
+ baseflags == ios_base::oct || baseflags == ios_base::hex
+ ? static_cast<long>(static_cast<unsigned int>(val))
+ : static_cast<long>(val)). failed();
+</pre>
+
+<p>
+When val is of type unsigned short or unsigned int the formatting conversion
+occurs as if it performed the following code fragment:
+</p>
+
+<pre>
+bool failed = use_facet<
+ num_put<charT,ostreambuf_iterator<charT,traits> >
+ >(getloc()).put(*this, *this, fill(), static_cast<unsigned long>(val)).
+failed();
+</pre>
+
+<p>
+When val is of type float the formatting conversion occurs as if it
+performed the following code fragment:
+</p>
+
+<pre>
+bool failed = use_facet<
+ num_put<charT,ostreambuf_iterator<charT,traits> >
+ >(getloc()).put(*this, *this, fill(), static_cast<double>(val)).
+failed();
+</pre>
+
+</blockquote>
+
+<p><i>[post-Toronto: This differs from the previous proposed
+resolution; PJP provided the new wording. The differences are in
+signed short and int output.]</i></p>
+<p><b>Rationale:</b></p>
+<p>The original proposed resolution was to cast int and short to long,
+unsigned int and unsigned short to unsigned long, and float to double,
+thus ensuring that we don't try to use nonexistent num_put<>
+member functions. The current proposed resolution is more
+complicated, but gives more expected results for hex and octal output
+of signed short and signed int. (On a system with 16-bit short, for
+example, printing short(-1) in hex format should yield 0xffff.)</p>
+<hr>
<a name="118"><h3>118. <tt>basic_istream</tt> uses nonexistent <tt>num_get</tt> member functions</h3></a><p>
<b>Section:</b> 27.6.1.2.2 <a href="lib-iostreams.html#lib.istream.formatted.arithmetic"> [lib.istream.formatted.arithmetic]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 20 Nov 1998</p>
<p>Formatted input is defined for the types <tt>short</tt>, <tt>unsigned short</tt>, <tt>int</tt>,
use_facet< numget >(loc).get(*this, 0, *this, err, val);
setstate(err);</pre>
-<p>According to section 22.2.2.1.1 , however,
+<p>According to section 22.2.2.1.1 <a href="lib-locales.html#lib.facet.num.get.members"> [lib.facet.num.get.members]</a>, however,
<tt>num_get<>::get()</tt> is only overloaded for the types
<tt>bool</tt>, <tt>long</tt>, <tt>unsigned short</tt>, <tt>unsigned
int</tt>, <tt>unsigned long</tt>, <tt>unsigned long</tt>,
that 27.6.1.2.2 is using a nonexistent function for types
<tt>short</tt> and <tt>int</tt>. </p>
<p><b>Proposed resolution:</b></p>
-<p>In 27.6.1.2.2 Arithmetic Extractors, remove the
+<p>In 27.6.1.2.2 <a href="lib-iostreams.html#lib.istream.formatted.arithmetic"> [lib.istream.formatted.arithmetic]</a> Arithmetic Extractors, remove the
two lines (1st and 3rd) which read:</p>
<blockquote>
<pre>operator>>(short& val);
<hr>
<a name="119"><h3>119. Should virtual functions be allowed to strengthen the exception specification?</h3></a><p>
<b>Section:</b> 17.4.4.8 <a href="lib-intro.html#lib.res.on.exception.handling"> [lib.res.on.exception.handling]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Judy Ward <b>Date:</b> 15 Dec 1998</p>
-<p>Section 17.4.4.8 states: </p>
+<p>Section 17.4.4.8 <a href="lib-intro.html#lib.res.on.exception.handling"> [lib.res.on.exception.handling]</a> states: </p>
<p>"An implementation may strengthen the exception-specification
for a function by removing listed exceptions." </p>
// overridden virtual function ios_base::failure::~failure()
};</pre>
<p><b>Proposed resolution:</b></p>
-<p>Change Section 17.4.4.8 from:</p>
+<p>Change Section 17.4.4.8 <a href="lib-intro.html#lib.res.on.exception.handling"> [lib.res.on.exception.handling]</a> from:</p>
<p> "may strengthen the
exception-specification for a function"</p>
<p>It doesn't seem this was intended, since Section 27.5 has them declared as typedefs. </p>
<p><b>Proposed resolution:</b></p>
-<p>Remove 27.5.2 paragraphs 2 and 3 (the above two
+<p>Remove 27.5.2 <a href="lib-iostreams.html#lib.streambuf"> [lib.streambuf]</a> paragraphs 2 and 3 (the above two
sentences). </p>
<p><b>Rationale:</b></p>
<p>The <tt>streambuf</tt> synopsis already has a declaration for the
<hr>
<a name="124"><h3>124. ctype_byname<charT>::do_scan_is & do_scan_not return type should be const charT*</h3></a><p>
<b>Section:</b> 22.2.1.2 <a href="lib-locales.html#lib.locale.ctype.byname"> [lib.locale.ctype.byname]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Judy Ward <b>Date:</b> 15 Dec 1998</p>
-<p>In Section 22.2.1.2
+<p>In Section 22.2.1.2 <a href="lib-locales.html#lib.locale.ctype.byname"> [lib.locale.ctype.byname]</a>
ctype_byname<charT>::do_scan_is() and do_scan_not() are declared
to return a const char* not a const charT*. </p>
<p><b>Proposed resolution:</b></p>
-<p>Change Section 22.2.1.2 <tt>do_scan_is()</tt> and
+<p>Change Section 22.2.1.2 <a href="lib-locales.html#lib.locale.ctype.byname"> [lib.locale.ctype.byname]</a> <tt>do_scan_is()</tt> and
<tt>do_scan_not()</tt> to return a <tt> const
charT*</tt>. </p>
<hr>
<a name="125"><h3>125. valarray<T>::operator!() return type is inconsistent</h3></a><p>
<b>Section:</b> 26.3.2 <a href="lib-numerics.html#lib.template.valarray"> [lib.template.valarray]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Judy Ward <b>Date:</b> 15 Dec 1998</p>
-<p>In Section 26.3.2 valarray<T>::operator!() is
-declared to return a valarray<T>, but in Section 26.3.2.5 it is declared to return a valarray<bool>. The
+<p>In Section 26.3.2 <a href="lib-numerics.html#lib.template.valarray"> [lib.template.valarray]</a> valarray<T>::operator!() is
+declared to return a valarray<T>, but in Section 26.3.2.5 <a href="lib-numerics.html#lib.valarray.unary"> [lib.valarray.unary]</a> it is declared to return a valarray<bool>. The
latter appears to be correct. </p>
<p><b>Proposed resolution:</b></p>
-<p>Change in Section 26.3.2 the declaration of
+<p>Change in Section 26.3.2 <a href="lib-numerics.html#lib.template.valarray"> [lib.template.valarray]</a> the declaration of
<tt>operator!()</tt> so that the return type is
<tt>valarray<bool></tt>. </p>
<hr>
<b>Section:</b> 22.2.1.1.2 <a href="lib-locales.html#lib.locale.ctype.virtuals"> [lib.locale.ctype.virtuals]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Judy Ward <b>Date:</b> 15 Dec 1998</p>
<p>Typos in 22.2.1.1.2 need to be fixed.</p>
<p><b>Proposed resolution:</b></p>
-<p>In Section 22.2.1.1.2 change: </p>
+<p>In Section 22.2.1.1.2 <a href="lib-locales.html#lib.locale.ctype.virtuals"> [lib.locale.ctype.virtuals]</a> change: </p>
<pre> do_widen(do_narrow(c),0) == c</pre>
<p>Tokyo: The LWG removed the following from the proposed resolution:</p>
- <p>In 20.4.5 , paragraph 2, and 20.4.5.3 ,
+ <p>In 20.4.5 <a href="lib-utilities.html#lib.auto.ptr"> [lib.auto.ptr]</a>, paragraph 2, and 20.4.5.3 <a href="lib-utilities.html#lib.auto.ptr.conv"> [lib.auto.ptr.conv]</a>,
paragraph 2, make the conversion to auto_ptr_ref const:</p>
<blockquote>
<pre>template<class Y> operator auto_ptr_ref<Y>() const throw();</pre>
</blockquote>
<p><b>Proposed resolution:</b></p>
-<p>In 20.4.5 , paragraph 2, move
+<p>In 20.4.5 <a href="lib-utilities.html#lib.auto.ptr"> [lib.auto.ptr]</a>, paragraph 2, move
the <tt>auto_ptr_ref</tt> definition to namespace scope.</p>
-<p>In 20.4.5 , paragraph 2, add
+<p>In 20.4.5 <a href="lib-utilities.html#lib.auto.ptr"> [lib.auto.ptr]</a>, paragraph 2, add
a public assignment operator to the <tt>auto_ptr</tt> definition: </p>
<blockquote>
<pre>auto_ptr& operator=(auto_ptr_ref<X> r) throw();</pre>
</blockquote>
-<p>Also add the assignment operator to 20.4.5.3 : </p>
+<p>Also add the assignment operator to 20.4.5.3 <a href="lib-utilities.html#lib.auto.ptr.conv"> [lib.auto.ptr.conv]</a>: </p>
<blockquote>
<pre>auto_ptr& operator=(auto_ptr_ref<X> r) throw()</pre>
stream state in case of failure.</p>
<p><b>Proposed resolution:</b></p>
<p>Add to the Effects: clause of seekg() in
-27.6.1.3 and to the Effects: clause of seekp() in
-27.6.2.4 : </p>
+27.6.1.3 <a href="lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a> and to the Effects: clause of seekp() in
+27.6.2.4 <a href="lib-iostreams.html#lib.ostream.seeks"> [lib.ostream.seeks]</a>: </p>
<blockquote>
<p>In case of failure, the function calls <tt>setstate(failbit)</tt> (which may throw <tt>ios_base::failure</tt>).
<b>Section:</b> 23.3.1 <a href="lib-containers.html#lib.map"> [lib.map]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Howard Hinnant <b>Date:</b> 6 Mar 1999</p>
<p>The title says it all.</p>
<p><b>Proposed resolution:</b></p>
-<p>Insert in 23.3.1 , paragraph 2,
+<p>Insert in 23.3.1 <a href="lib-containers.html#lib.map"> [lib.map]</a>, paragraph 2,
after operator= in the map declaration:</p>
<pre> allocator_type get_allocator() const;</pre>
<p>This appears to be overly restrictive, dictating the precise memory/performance
tradeoff for the implementor.</p>
<p><b>Proposed resolution:</b></p>
-<p>Change 23.2.4.1 , paragraph 1 to:</p>
+<p>Change 23.2.4.1 <a href="lib-containers.html#lib.vector.cons"> [lib.vector.cons]</a>, paragraph 1 to:</p>
<p>-1- Complexity: The constructor template <class
InputIterator> vector(InputIterator first, InputIterator last)
<hr>
<a name="137"><h3>137. Do use_facet and has_facet look in the global locale?</h3></a><p>
<b>Section:</b> 22.1.1 <a href="lib-locales.html#lib.locale"> [lib.locale]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Angelika Langer <b>Date:</b> 17 Mar 1999</p>
-<p>Section 22.1.1 says:</p>
+<p>Section 22.1.1 <a href="lib-locales.html#lib.locale"> [lib.locale]</a> says:</p>
<p>-4- In the call to use_facet<Facet>(loc), the type argument
chooses a facet, making available all members of the named type. If
function has_facet<Facet>(). </p>
<p>This contradicts the specification given in section
-22.1.2 :
+22.1.2 <a href="lib-locales.html#lib.locale.global.templates"> [lib.locale.global.templates]</a>:
<br><br>
template <class Facet> const Facet& use_facet(const
locale& loc); <br>
right! (and Matt states this complexity in his book)</p>
<p><b>Proposed resolution:</b></p>
-<p>Change 25.3.8 complexity to:</p>
+<p>Change 25.3.8 <a href="lib-algorithms.html#lib.alg.lex.comparison"> [lib.alg.lex.comparison]</a> complexity to:</p>
<blockquote>
At most <tt>2*min((last1 - first1), (last2 - first2))</tt>
applications of the corresponding comparison.
library. Regarding the issue of padding in the inserter, I don't know
what the intent was. </p>
<p><b>Proposed resolution:</b></p>
-<p>After 26.2.6 paragraph 14 (operator>>), add a
+<p>After 26.2.6 <a href="lib-numerics.html#lib.complex.ops"> [lib.complex.ops]</a> paragraph 14 (operator>>), add a
Notes clause:</p>
<blockquote>
<hr>
<a name="148"><h3>148. Functions in the example facet BoolNames should be const</h3></a><p>
<b>Section:</b> 22.2.8 <a href="lib-locales.html#lib.facets.examples"> [lib.facets.examples]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Jeremy Siek <b>Date:</b> 3 Jun 1999</p>
-<p>In 22.2.8 paragraph 13, the do_truename() and
+<p>In 22.2.8 <a href="lib-locales.html#lib.facets.examples"> [lib.facets.examples]</a> paragraph 13, the do_truename() and
do_falsename() functions in the example facet BoolNames should be
const. The functions they are overriding in
numpunct_byname<char> are const. </p>
<p><b>Proposed resolution:</b></p>
-<p>In 22.2.8 paragraph 13, insert "const" in
+<p>In 22.2.8 <a href="lib-locales.html#lib.facets.examples"> [lib.facets.examples]</a> paragraph 13, insert "const" in
two places:</p>
<blockquote>
<p><tt>string do_truename() const { return "Oui Oui!"; }<br>
<a name="150"><h3>150. Find_first_of says integer instead of iterator </h3></a><p>
<b>Section:</b> 25.1.4 <a href="lib-algorithms.html#lib.alg.find.first.of"> [lib.alg.find.first.of]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Matt McClure <b>Date:</b> 30 Jun 1999</p>
<p><b>Proposed resolution:</b></p>
-<p>Change 25.1.4 paragraph 2 from:</p>
+<p>Change 25.1.4 <a href="lib-algorithms.html#lib.alg.find.first.of"> [lib.alg.find.first.of]</a> paragraph 2 from:</p>
<blockquote>
<p>Returns: The first iterator i in the range [first1, last1) such
argument. Also, in the effects clause (paragraph 3), the semantic is also kept
vague.</p>
<p><b>Proposed resolution:</b></p>
-<p>In 22.2.1.1.2 paragraphs 4 and 6, change the returns
+<p>In 22.2.1.1.2 <a href="lib-locales.html#lib.locale.ctype.virtuals"> [lib.locale.ctype.virtuals]</a> paragraphs 4 and 6, change the returns
clause from:</p>
<blockquote>
<p>"... such that <tt>is(*p)</tt>
one of them.</p>
<p><b>Proposed resolution:</b></p>
-<p>Change the returns clause in 22.2.1.3.2
+<p>Change the returns clause in 22.2.1.3.2 <a href="lib-locales.html#lib.facet.ctype.char.members"> [lib.facet.ctype.char.members]</a>
paragraph 10 from:</p>
<p> Returns: do_widen(low, high, to).</p>
<p> Returns: do_widen(c) or do_widen(low, high, to),
respectively.</p>
-<p>Change 22.2.1.3.2 paragraph 10 and 11 from:</p>
+<p>Change 22.2.1.3.2 <a href="lib-locales.html#lib.facet.ctype.char.members"> [lib.facet.ctype.char.members]</a> paragraph 10 and 11 from:</p>
<pre> char narrow(char c, char /*dfault*/) const;
const char* narrow(const char* low, const char* high,
char /*dfault*/, char* to) const;</pre>
(the missing length modifier for <tt>scanf()</tt> when scanning <tt>double</tt>s
is actually a problem I found quite often in production code, too).</p>
<p><b>Proposed resolution:</b></p>
-<p>In 22.2.2.1.2 , paragraph 7, add a row in the Length
+<p>In 22.2.2.1.2 <a href="lib-locales.html#lib.facet.num.get.virtuals"> [lib.facet.num.get.virtuals]</a>, paragraph 7, add a row in the Length
Modifier table to say that for <tt>double</tt> a length modifier
<tt>l</tt> is to be used.</p>
<p><b>Rationale:</b></p>
</h3></a><p>
<b>Section:</b> 27.3 <a href="lib-iostreams.html#lib.iostream.objects"> [lib.iostream.objects]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Jul 1999</p>
<p>There are conflicting statements about where the class
-<tt>Init</tt> is defined. According to 27.3 paragraph 2
-it is defined as <tt>basic_ios::Init</tt>, according to 27.4.2 it is defined as <tt>ios_base::Init</tt>.</p>
+<tt>Init</tt> is defined. According to 27.3 <a href="lib-iostreams.html#lib.iostream.objects"> [lib.iostream.objects]</a> paragraph 2
+it is defined as <tt>basic_ios::Init</tt>, according to 27.4.2 <a href="lib-iostreams.html#lib.ios.base"> [lib.ios.base]</a> it is defined as <tt>ios_base::Init</tt>.</p>
<p><b>Proposed resolution:</b></p>
-<p>Change 27.3 paragraph 2 from
+<p>Change 27.3 <a href="lib-iostreams.html#lib.iostream.objects"> [lib.iostream.objects]</a> paragraph 2 from
"<tt>basic_ios::Init"</tt> to
"<tt>ios_base::Init"</tt>.</p>
<p><b>Rationale:</b></p>
<a name="156"><h3>156. Typo in <tt>imbue()</tt> description</h3></a><p>
<b>Section:</b> 27.4.2.3 <a href="lib-iostreams.html#lib.ios.base.locales"> [lib.ios.base.locales]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Jul 1999</p>
<p>There is a small discrepancy between the declarations of
-<tt>imbue()</tt>: in 27.4.2 the argument is passed as
-<tt>locale const&</tt> (correct), in 27.4.2.3 it
+<tt>imbue()</tt>: in 27.4.2 <a href="lib-iostreams.html#lib.ios.base"> [lib.ios.base]</a> the argument is passed as
+<tt>locale const&</tt> (correct), in 27.4.2.3 <a href="lib-iostreams.html#lib.ios.base.locales"> [lib.ios.base.locales]</a> it
is passed as <tt>locale const</tt> (wrong).</p>
<p><b>Proposed resolution:</b></p>
-<p>In 27.4.2.3 change the <tt>imbue</tt> argument
+<p>In 27.4.2.3 <a href="lib-iostreams.html#lib.ios.base.locales"> [lib.ios.base.locales]</a> change the <tt>imbue</tt> argument
from "<tt>locale const" to "locale
const&".</tt>
</p>
themselves, the default behavior of <tt>setbuf()</tt> should always be
to do nothing.</p>
<p><b>Proposed resolution:</b></p>
-<p>Change 27.5.2.4.2 , paragraph 3, Default behavior,
+<p>Change 27.5.2.4.2 <a href="lib-iostreams.html#lib.streambuf.virt.buffer"> [lib.streambuf.virt.buffer]</a>, paragraph 3, Default behavior,
to: "Default behavior: Does nothing. Returns this."</p>
<hr>
<a name="159"><h3>159. Strange use of <tt>underflow()</tt>
it, <tt>uflow()</tt> would extract the current character. This should
be fixed to use <tt>sbumpc()</tt> instead.</p>
<p><b>Proposed resolution:</b></p>
-<p>Change 27.5.2.4.3 paragraph 1,
+<p>Change 27.5.2.4.3 <a href="lib-iostreams.html#lib.streambuf.virt.get"> [lib.streambuf.virt.get]</a> paragraph 1,
<tt>showmanyc()</tt>returns clause, by replacing the word
"supplied" with the words "extracted from the
stream".</p>
is not defined. Probably, the referred function is
<tt>basic_ios<>::exceptions()</tt>.</p>
<p><b>Proposed resolution:</b></p>
-<p>In 27.6.1.1 , 27.6.1.3 , paragraph 1,
-27.6.2.1 , paragraph 3, and 27.6.2.5.1 ,
+<p>In 27.6.1.1 <a href="lib-iostreams.html#lib.istream"> [lib.istream]</a>, 27.6.1.3 <a href="lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a>, paragraph 1,
+27.6.2.1 <a href="lib-iostreams.html#lib.ostream"> [lib.ostream]</a>, paragraph 3, and 27.6.2.5.1 <a href="lib-iostreams.html#lib.ostream.formatted.reqmts"> [lib.ostream.formatted.reqmts]</a>,
paragraph 1, change "<tt>exception()" to
"exceptions()"</tt>.</p>
is an object of type <tt>istream_iterator</tt>. This is wrong: It is
an object of type <tt>istreambuf_iterator</tt>.</p>
<p><b>Proposed resolution:</b></p>
-<p>Change 27.6.1.2.2 from:</p>
+<p>Change 27.6.1.2.2 <a href="lib-iostreams.html#lib.istream.formatted.arithmetic"> [lib.istream.formatted.arithmetic]</a> from:</p>
<blockquote>
<p>The first argument provides an object of the istream_iterator class...</p>
</blockquote>
<hr>
<a name="164"><h3>164. do_put() has apparently unused fill argument</h3></a><p>
<b>Section:</b> 22.2.5.3.2 <a href="lib-locales.html#lib.locale.time.put.virtuals"> [lib.locale.time.put.virtuals]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Angelika Langer <b>Date:</b> 23 Jul 1999</p>
-<p>In 22.2.5.3.2 the do_put() function is specified
+<p>In 22.2.5.3.2 <a href="lib-locales.html#lib.locale.time.put.virtuals"> [lib.locale.time.put.virtuals]</a> the do_put() function is specified
as taking a fill character as an argument, but the description of the
function does not say whether the character is used at all and, if so,
in which way. The same holds for any format control parameters that
time_put.do_put() looks inconsistent to me.<br> <br> Is the
signature of do_put() wrong, or is the effects clause incomplete?</p>
<p><b>Proposed resolution:</b></p>
-<p>Add the following note after 22.2.5.3.2
+<p>Add the following note after 22.2.5.3.2 <a href="lib-locales.html#lib.locale.time.put.virtuals"> [lib.locale.time.put.virtuals]</a>
paragraph 2:</p>
<blockquote>
<p> [Note: the <tt>fill</tt> argument may be used in the implementation-defined formats, or by derivations. A space character is a reasonable default
in <i>formatted</i> output functions. Probably this is a typo and the
paragraph really want to describe unformatted output functions...</p>
<p><b>Proposed resolution:</b></p>
-<p>In 27.6.2.6 paragraph 1, the first and last
+<p>In 27.6.2.6 <a href="lib-iostreams.html#lib.ostream.unformatted"> [lib.ostream.unformatted]</a> paragraph 1, the first and last
sentences, change the word "formatted" to
"unformatted":</p>
<blockquote>
<p>Paragraph 8, Notes, of this section seems to mandate an extremely
inefficient way of buffer handling for <tt>basic_stringbuf</tt>,
especially in view of the restriction that <tt>basic_ostream</tt>
-member functions are not allowed to use <tt>xsputn()</tt> (see 27.6.2.1 ): For each character to be inserted, a new buffer
+member functions are not allowed to use <tt>xsputn()</tt> (see 27.6.2.1 <a href="lib-iostreams.html#lib.ostream"> [lib.ostream]</a>): For each character to be inserted, a new buffer
is to be created.</p>
<p>Of course, the resolution below requires some handling of
simultaneous input and output since it is no longer possible to update
<tt>egptr()</tt> whenever <tt>epptr()</tt> is changed. A possible
solution is to handle this in <tt>underflow()</tt>.</p>
<p><b>Proposed resolution:</b></p>
-<p>In 27.7.1.3 paragraph 8, Notes, insert the words
+<p>In 27.7.1.3 <a href="lib-iostreams.html#lib.stringbuf.virtuals"> [lib.stringbuf.virtuals]</a> paragraph 8, Notes, insert the words
"at least" as in the following:</p>
<blockquote>
<p>To make a write position available, the function reallocates (or initially
<a name="170"><h3>170. Inconsistent definition of <tt>traits_type</tt>
</h3></a><p>
<b>Section:</b> 27.7.4 <a href="lib-iostreams.html#lib.stringstream"> [lib.stringstream]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Jul 1999</p>
-<p>The classes <tt>basic_stringstream</tt> (27.7.4 ),
-<tt>basic_istringstream</tt> (27.7.2 ), and
-<tt>basic_ostringstream</tt> (27.7.3 ) are inconsistent
+<p>The classes <tt>basic_stringstream</tt> (27.7.4 <a href="lib-iostreams.html#lib.stringstream"> [lib.stringstream]</a>),
+<tt>basic_istringstream</tt> (27.7.2 <a href="lib-iostreams.html#lib.istringstream"> [lib.istringstream]</a>), and
+<tt>basic_ostringstream</tt> (27.7.3 <a href="lib-iostreams.html#lib.ostringstream"> [lib.ostringstream]</a>) are inconsistent
in their definition of the type <tt>traits_type</tt>: For
<tt>istringstream</tt>, this type is defined, for the other two it is
not. This should be consistent.</p>
<p><b>Proposed resolution:</b></p>
<p><b>Proposed resolution:</b></p> <p>To the declarations of
-<tt>basic_ostringstream</tt> (27.7.3 ) and
-<tt>basic_stringstream</tt> (27.7.4 ) add:</p>
+<tt>basic_ostringstream</tt> (27.7.3 <a href="lib-iostreams.html#lib.ostringstream"> [lib.ostringstream]</a>) and
+<tt>basic_stringstream</tt> (27.7.4 <a href="lib-iostreams.html#lib.stringstream"> [lib.stringstream]</a>) add:</p>
<blockquote>
<pre>typedef traits traits_type;</pre>
</blockquote>
<hr>
<a name="171"><h3>171. Strange <tt>seekpos()</tt> semantics due to joint position</h3></a><p>
<b>Section:</b> 27.8.1.4 <a href="lib-iostreams.html#lib.filebuf.virtuals"> [lib.filebuf.virtuals]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Jul 1999</p>
-<p>Overridden virtual functions, seekpos()</p> <p>In 27.8.1.1 paragraph 3, it is stated that a joint input and
+<p>Overridden virtual functions, seekpos()</p> <p>In 27.8.1.1 <a href="lib-iostreams.html#lib.filebuf"> [lib.filebuf]</a> paragraph 3, it is stated that a joint input and
output position is maintained by <tt>basic_filebuf</tt>. Still, the
description of <tt>seekpos()</tt> seems to talk about different file
positions. In particular, it is unclear (at least to me) what is
<a name="172"><h3>172. Inconsistent types for <tt>basic_istream::ignore()</tt>
</h3></a><p>
<b>Section:</b> 27.6.1.3 <a href="lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Greg Comeau, Dietmar Kühl <b>Date:</b> 23 Jul 1999</p>
-<p>In 27.6.1.1 the function
+<p>In 27.6.1.1 <a href="lib-iostreams.html#lib.istream"> [lib.istream]</a> the function
<tt>ignore()</tt> gets an object of type <tt>streamsize</tt> as first
-argument. However, in 27.6.1.3
+argument. However, in 27.6.1.3 <a href="lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a>
paragraph 23 the first argument is of type <tt>int.</tt>
</p>
to show a first parameter of type streamsize and use
numeric_limits<streamsize>::max.</p>
<p><b>Proposed resolution:</b></p>
-<p>In 27.6.1.3 paragraph 23 and 24, change both uses
+<p>In 27.6.1.3 <a href="lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a> paragraph 23 and 24, change both uses
of <tt>int</tt> in the description of <tt>ignore()</tt> to
<tt>streamsize</tt>.</p>
<hr>
<b>Section:</b> 27.8.1.4 <a href="lib-iostreams.html#lib.filebuf.virtuals"> [lib.filebuf.virtuals]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Greg Comeau, Dietmar Kühl <b>Date:</b> 23 Jul 1999</p>
<p>
-In 27.8.1.1 the function <tt>setbuf()</tt> gets an
+In 27.8.1.1 <a href="lib-iostreams.html#lib.filebuf"> [lib.filebuf]</a> the function <tt>setbuf()</tt> gets an
object of type <tt>streamsize</tt> as second argument. However, in
-27.8.1.4 paragraph 9 the second argument is of type
+27.8.1.4 <a href="lib-iostreams.html#lib.filebuf.virtuals"> [lib.filebuf.virtuals]</a> paragraph 9 the second argument is of type
<tt>int</tt>.
</p>
</p>
<p><b>Proposed resolution:</b></p>
-<p>In 27.8.1.4 paragraph 9, change all uses of
+<p>In 27.8.1.4 <a href="lib-iostreams.html#lib.filebuf.virtuals"> [lib.filebuf.virtuals]</a> paragraph 9, change all uses of
<tt>int</tt> in the description of <tt>setbuf()</tt> to
<tt>streamsize</tt>.</p>
<hr>
paragraph 6 the <tt>streampos</tt> gets the type <tt>POS_T</tt>
</p>
<p><b>Proposed resolution:</b></p>
-<p>Change D.6 paragraph 1 from "<tt>typedef
+<p>Change D.6 <a href="future.html#depr.ios.members"> [depr.ios.members]</a> paragraph 1 from "<tt>typedef
OFF_T streampos;</tt>" to "<tt>typedef POS_T
streampos;</tt>"</p>
<hr>
version because now the arguments are absolutely identical if the last
argument is not specified.</p>
<p><b>Proposed resolution:</b></p>
-<p>In D.6 paragraph 8, remove the default arguments for
+<p>In D.6 <a href="future.html#depr.ios.members"> [depr.ios.members]</a> paragraph 8, remove the default arguments for
<tt>basic_streambuf::pubseekpos()</tt>,
<tt>basic_ifstream::open()</tt>, and
<tt>basic_ofstream::open().</tt>
this function defined in class <tt>ios_base</tt>. However, this is not
the case. Thus, it is hard to tell how the semantics (paragraph 9) can
be implemented: "Call the corresponding member function specified
-in clause 27 ."</p>
+in clause 27 <a href="lib-iostreams.html#lib.input.output"> [lib.input.output]</a>."</p>
<p><b>Proposed resolution:</b></p>
-<p>In D.6 paragraph 8, move the declaration of the
+<p>In D.6 <a href="future.html#depr.ios.members"> [depr.ios.members]</a> paragraph 8, move the declaration of the
function <tt>exceptions()</tt>into class <tt>basic_ios</tt>.</p>
<hr>
<a name="181"><h3>181. make_pair() unintended behavior</h3></a><p>
I doubt anyone intended that behavior...
</p>
<p><b>Proposed resolution:</b></p>
-<p>In 20.2 , paragraph 1 change the following
+<p>In 20.2 <a href="lib-utilities.html#lib.utility"> [lib.utility]</a>, paragraph 1 change the following
declaration of make_pair():</p>
<blockquote>
<pre>template <class T1, class T2> pair<T1,T2> make_pair(const T1&, const T2&);</pre>
<blockquote>
<pre>template <class T1, class T2> pair<T1,T2> make_pair(T1, T2);</pre>
</blockquote>
-<p> In 20.2.2 paragraph 7 and the line before, change:</p>
+<p> In 20.2.2 <a href="lib-utilities.html#lib.pairs"> [lib.pairs]</a> paragraph 7 and the line before, change:</p>
<blockquote>
<pre>template <class T1, class T2>
pair<T1, T2> make_pair(const T1& x, const T2& y);</pre>
advantages of the solution. Two implementors reported that the
proposed resolution passed their test suites.</p>
<hr>
+<a name="182"><h3>182. Ambiguous references to size_t</h3></a><p>
+<b>Section:</b> 17 <a href="lib-intro.html#lib.library"> [lib.library]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Al Stevens <b>Date:</b> 15 Aug 1999</p>
+<p>Many references to <tt> size_t</tt> throughout the document
+omit the <tt> std::</tt> namespace qualification.</p> <p>For
+example, 17.4.3.4 <a href="lib-intro.html#lib.replacement.functions"> [lib.replacement.functions]</a> paragraph 2:</p>
+<blockquote>
+<pre>— operator new(size_t)
+— operator new(size_t, const std::nothrow_t&)
+— operator new[](size_t)
+— operator new[](size_t, const std::nothrow_t&)</pre>
+</blockquote>
+<p><b>Proposed resolution:</b></p>
+<p> In 17.4.3.4 <a href="lib-intro.html#lib.replacement.functions"> [lib.replacement.functions]</a> paragraph 2: replace:</p>
+<blockquote>
+<p><tt> - operator new(size_t)<br>
+ - operator new(size_t, const std::nothrow_t&)<br>
+ - operator new[](size_t)<br>
+ - operator new[](size_t, const std::nothrow_t&)</tt></p>
+</blockquote>
+<p> by:</p>
+<blockquote>
+<pre>- operator new(std::size_t)
+- operator new(std::size_t, const std::nothrow_t&)
+- operator new[](std::size_t)
+- operator new[](std::size_t, const std::nothrow_t&)</pre>
+</blockquote>
+<p>In [lib.allocator.requirements] 20.1.5, paragraph 4: replace:</p>
+<blockquote>
+ <p>The typedef members pointer, const_pointer, size_type, and difference_type
+ are required to be T*, T const*, size_t, and ptrdiff_t, respectively.</p>
+</blockquote>
+<p> by:</p>
+<blockquote>
+ <p>The typedef members pointer, const_pointer, size_type, and difference_type
+ are required to be T*, T const*, std::size_t, and std::ptrdiff_t,
+ respectively.</p>
+</blockquote>
+<p>In [lib.allocator.members] 20.4.1.1, paragraphs 3 and 6: replace:</p>
+<blockquote>
+ <p>3 Notes: Uses ::operator new(size_t) (18.4.1).</p>
+ <p>6 Note: the storage is obtained by calling ::operator new(size_t), but it
+ is unspecified when or how often this function is called. The use of hint is
+ unspecified, but intended as an aid to locality if an implementation so
+ desires.</p>
+</blockquote>
+<p>by:</p>
+<blockquote>
+ <p>3 Notes: Uses ::operator new(std::size_t) (18.4.1).</p>
+ <p>6 Note: the storage is obtained by calling ::operator new(std::size_t), but
+ it is unspecified when or how often this function is called. The use of hint
+ is unspecified, but intended as an aid to locality if an implementation so
+ desires.</p>
+</blockquote>
+<p>In [lib.char.traits.require] 21.1.1, paragraph 1: replace:</p>
+<blockquote>
+ <p>In Table 37, X denotes a Traits class defining types and functions for the
+ character container type CharT; c and d denote values of type CharT; p and q
+ denote values of type const CharT*; s denotes a value of type CharT*; n, i and
+ j denote values of type size_t; e and f denote values of type X::int_type; pos
+ denotes a value of type X::pos_type; and state denotes a value of type X::state_type.</p>
+</blockquote>
+<p>by:</p>
+<blockquote>
+ <p>In Table 37, X denotes a Traits class defining types and functions for the
+ character container type CharT; c and d denote values of type CharT; p and q
+ denote values of type const CharT*; s denotes a value of type CharT*; n, i and
+ j denote values of type std::size_t; e and f denote values of type X::int_type;
+ pos denotes a value of type X::pos_type; and state denotes a value of type X::state_type.</p>
+</blockquote>
+<p>In [lib.char.traits.require] 21.1.1, table 37: replace the return type of
+X::length(p): "size_t" by "std::size_t".</p>
+<p> In [lib.std.iterator.tags] 24.3.3, paragraph 2: replace:<br>
+ typedef ptrdiff_t difference_type;<br>
+ by:<br>
+ typedef std::ptrdiff_t difference_type;</p>
+<p> In [lib.locale.ctype] 22.2.1.1 put namespace std { ...} around the declaration of template <class charT> class ctype.<br>
+<br>
+ In [lib.iterator.traits] 24.3.1, paragraph 2 put namespace std { ...} around the declaration of:<br>
+<br>
+ template<class Iterator> struct iterator_traits<br>
+ template<class T> struct iterator_traits<T*><br>
+ template<class T> struct iterator_traits<const T*></p>
+<p><b>Rationale:</b></p>
+<p>The LWG believes correcting names like <tt>size_t</tt> and
+<tt>ptrdiff_t</tt> to <tt>std::size_t</tt> and <tt>std::ptrdiff_t</tt>
+to be essentially editorial. There there can't be another size_t or
+ptrdiff_t meant anyway because, according to 17.4.3.1.4 <a href="lib-intro.html#lib.extern.types"> [lib.extern.types]</a>,</p>
+
+<blockquote>
+For each type T from the Standard C library, the types ::T and std::T
+are reserved to the implementation and, when defined, ::T shall be
+identical to std::T.
+</blockquote>
+
+<p>The issue is treated as a Defect Report to make explicit the Project
+Editor's authority to make this change.</p>
+
+<p><i>[Post-Tokyo: Nico Josuttis provided the above wording at the
+request of the LWG.]</i></p>
+
+<p><i>[Toronto: This is tangentially related to issue <a href="lwg-active.html#229">229</a>, but only tangentially: the intent of this issue is to
+address use of the name <tt>size_t</tt> in contexts outside of
+namespace std, such as in the description of <tt>::operator new</tt>.
+The proposed changes should be reviewed to make sure they are
+correct.]</i></p>
+
+<p><i>[pre-Copenhagen: Nico has reviewed the changes and believes
+them to be correct.]</i></p>
+
+<hr>
<a name="183"><h3>183. I/O stream manipulators don't work for wide character streams</h3></a><p>
<b>Section:</b> 27.6.3 <a href="lib-iostreams.html#lib.std.manip"> [lib.std.manip]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Andy Sawyer <b>Date:</b> 7 Jul 1999</p>
-<p>27.6.3 paragraph 3 says (clause numbering added for
-exposition):<a href="lib-iostreams.html#lib.std.manip"> [lib.std.manip]</a>
-</p>
+<p>27.6.3 <a href="lib-iostreams.html#lib.std.manip"> [lib.std.manip]</a> paragraph 3 says (clause numbering added for
+exposition):</p>
<blockquote>
<p>Returns: An object s of unspecified type such that if [1] out is an (instance
of) basic_ostream then the expression out<<s behaves as if f(s) were
that the value of the expression is "the same specialization of
basic_ostream as out"&</p>
<p><b>Proposed resolution:</b></p>
-<p>Replace section 27.6.3 except paragraph 1 with the
+<p>Replace section 27.6.3 <a href="lib-iostreams.html#lib.std.manip"> [lib.std.manip]</a> except paragraph 1 with the
following:</p>
<blockquote>
<p>2- The type designated smanip in each of the following function descriptions is implementation-specified and may be different for each
<a name="184"><h3>184. numeric_limits<bool> wording problems</h3></a><p>
<b>Section:</b> 18.2.1.5 <a href="lib-support.html#lib.numeric.special"> [lib.numeric.special]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Gabriel Dos Reis <b>Date:</b> 21 Jul 1999</p>
<p>bools are defined by the standard to be of integer types, as per
-3.9.1 paragraph 7. However "integer types"
+3.9.1 <a href="basic.html#basic.fundamental"> [basic.fundamental]</a> paragraph 7. However "integer types"
seems to have a special meaning for the author of 18.2. The net effect
is an unclear and confusing specification for
numeric_limits<bool> as evidenced below.</p>
<p>Furthermore, numeric_limits<bool>::is_modulo and
numeric_limits<bool>::is_signed have similar problems.</p>
<p><b>Proposed resolution:</b></p>
-<p>Append to the end of 18.2.1.5 :</p>
+<p>Append to the end of 18.2.1.5 <a href="lib-support.html#lib.numeric.special"> [lib.numeric.special]</a>:</p>
<blockquote>
<p>The specialization for bool shall be provided as follows:</p>
<pre> namespace std {
<hr>
<a name="185"><h3>185. Questionable use of term "inline"</h3></a><p>
<b>Section:</b> 20.3 <a href="lib-utilities.html#lib.function.objects"> [lib.function.objects]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> UK Panel <b>Date:</b> 26 Jul 1999</p>
-<p>Paragraph 4 of 20.3 says:</p>
+<p>Paragraph 4 of 20.3 <a href="lib-utilities.html#lib.function.objects"> [lib.function.objects]</a> says:</p>
<blockquote>
<p> [Example: To negate every element of a: transform(a.begin(), a.end(),
a.begin(), negate<double>()); The corresponding functions will inline
<p>Thus the example "mandates" behavior that is explicitly
not required elsewhere.</p>
<p><b>Proposed resolution:</b></p>
-<p>In 20.3 paragraph 1, remove the sentence:</p>
+<p>In 20.3 <a href="lib-utilities.html#lib.function.objects"> [lib.function.objects]</a> paragraph 1, remove the sentence:</p>
<blockquote>
<p>They are important for the effective use of the library.</p>
</blockquote>
-<p>Remove 20.3 paragraph 2, which reads:</p>
+<p>Remove 20.3 <a href="lib-utilities.html#lib.function.objects"> [lib.function.objects]</a> paragraph 2, which reads:</p>
<blockquote>
<p> Using function objects together with function templates
increases the expressive power of the library as well as making the
resulting code much more efficient.</p>
</blockquote>
-<p>In 20.3 paragraph 4, remove the sentence:</p>
+<p>In 20.3 <a href="lib-utilities.html#lib.function.objects"> [lib.function.objects]</a> paragraph 4, remove the sentence:</p>
<blockquote>
<p>The corresponding functions will inline the addition and the
negation.</p>
<hr>
<a name="186"><h3>186. bitset::set() second parameter should be bool</h3></a><p>
<b>Section:</b> 23.3.5.2 <a href="lib-containers.html#lib.bitset.members"> [lib.bitset.members]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Darin Adler <b>Date:</b> 13 Aug 1999</p>
-<p>In section 23.3.5.2 , paragraph 13 defines the
+<p>In section 23.3.5.2 <a href="lib-containers.html#lib.bitset.members"> [lib.bitset.members]</a>, paragraph 13 defines the
bitset::set operation to take a second parameter of type int. The
function tests whether this value is non-zero to determine whether to
set the bit to true or false. The type of this second parameter should
happen with bool, since conversion to bool has the semantic of
translating 0 to false and any non-zero value to true.</p>
<p><b>Proposed resolution:</b></p>
-<p>In 23.3.5 Para 1 Replace:</p>
+<p>In 23.3.5 <a href="lib-containers.html#lib.template.bitset"> [lib.template.bitset]</a> Para 1 Replace:</p>
<blockquote>
<pre>bitset<N>& set(size_t pos, int val = true ); </pre>
</blockquote>
<blockquote>
<pre>bitset<N>& set(size_t pos, bool val = true );</pre>
</blockquote>
-<p>In 23.3.5.2 Para 12(.5) Replace:</p>
+<p>In 23.3.5.2 <a href="lib-containers.html#lib.bitset.members"> [lib.bitset.members]</a> Para 12(.5) Replace:</p>
<blockquote>
<pre>bitset<N>& set(size_t pos, int val = 1 );</pre>
</blockquote>
I would like the committee to look at the definition carefully and
correct the statement in 27.4.2.2</p>
<p><b>Proposed resolution:</b></p>
-<p>Remove from 27.4.2.2 , paragraph 9, the text
+<p>Remove from 27.4.2.2 <a href="lib-iostreams.html#lib.fmtflags.state"> [lib.fmtflags.state]</a>, paragraph 9, the text
"(number of digits after the decimal point)".</p>
<hr>
<a name="193"><h3>193. Heap operations description incorrect</h3></a><p>
priority queue as explained in 23.2.3.2.2 [lib.priqueue.members] (where I assume that a "priority queue" respects priority AND time).</p>
</blockquote>
<p><b>Proposed resolution:</b></p>
-<p>Change 25.3.6 property (1) from:</p>
+<p>Change 25.3.6 <a href="lib-algorithms.html#lib.alg.heap.operations"> [lib.alg.heap.operations]</a> property (1) from:</p>
<blockquote>
<p>(1) *a is the largest element</p>
</blockquote>
should set failbit. Should it set eofbit as well? The standard
doesn't seem to answer that question.</p>
-<p>On the one hand, nothing in 27.6.1.1.2 says that
+<p>On the one hand, nothing in 27.6.1.1.2 <a href="lib-iostreams.html#lib.istream::sentry"> [lib.istream::sentry]</a> says that
<tt>basic_istream<>::sentry</tt> should ever set eofbit. On the
-other hand, 27.6.1.1 paragraph 4 says that if
+other hand, 27.6.1.1 <a href="lib-iostreams.html#lib.istream"> [lib.istream]</a> paragraph 4 says that if
extraction from a <tt>streambuf</tt> "returns
<tt>traits::eof()</tt>, then the input function, except as explicitly
noted otherwise, completes its actions and does
<p>This would have an impact on existing code that expects past-the-end
iterators obtained from different (generic) containers being not equal.</p>
<p><b>Proposed resolution:</b></p>
-<p>Change 24.1 paragraph 5, the last sentence, from:</p>
+<p>Change 24.1 <a href="lib-iterators.html#lib.iterator.requirements"> [lib.iterator.requirements]</a> paragraph 5, the last sentence, from:</p>
<blockquote>
<p>Dereferenceable and past-the-end values are always non-singular.</p>
</blockquote>
<hr>
<a name="209"><h3>209. basic_string declarations inconsistent</h3></a><p>
<b>Section:</b> 21.3 <a href="lib-strings.html#lib.basic.string"> [lib.basic.string]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Igor Stauder <b>Date:</b> 11 Feb 2000</p>
-<p>In Section 21.3 the basic_string member function
+<p>In Section 21.3 <a href="lib-strings.html#lib.basic.string"> [lib.basic.string]</a> the basic_string member function
declarations use a consistent style except for the following functions:</p>
<blockquote>
<pre>void push_back(const charT);
- swap: redundant use of template parameters in argument
basic_string<charT,traits,Allocator>&</p>
<p><b>Proposed resolution:</b></p>
-<p>In Section 21.3 change the basic_string member
+<p>In Section 21.3 <a href="lib-strings.html#lib.basic.string"> [lib.basic.string]</a> change the basic_string member
function declarations push_back, assign, and swap to:</p>
<blockquote>
<pre>void push_back(charT c);
<hr>
<a name="210"><h3>210. distance first and last confused</h3></a><p>
<b>Section:</b> 25 <a href="lib-algorithms.html#lib.algorithms"> [lib.algorithms]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Lisa Lippincott <b>Date:</b> 15 Feb 2000</p>
-<p>In paragraph 9 of section 25 , it is written:</p>
+<p>In paragraph 9 of section 25 <a href="lib-algorithms.html#lib.algorithms"> [lib.algorithms]</a>, it is written:</p>
<blockquote>
<p> In the description of the algorithms operators + and - are used
for some of the iterator categories for which they do not have to
</p>
</blockquote>
<p><b>Proposed resolution:</b></p>
-<p>On the last line of paragraph 9 of section 25 change
+<p>On the last line of paragraph 9 of section 25 <a href="lib-algorithms.html#lib.algorithms"> [lib.algorithms]</a> change
<tt>"a-b"</tt> to <tt>"b-a".</tt>
</p>
<p><b>Rationale:</b></p>
</blockquote>
<p>(which tests failbit) is not required to terminate at EOF.</p>
<p>Furthermore, this is inconsistent with other extraction operators,
-which do include this requirement. (See sections 27.6.1.2 and 27.6.1.3 ), where this
+which do include this requirement. (See sections 27.6.1.2 <a href="lib-iostreams.html#lib.istream.formatted"> [lib.istream.formatted]</a> and 27.6.1.3 <a href="lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a>), where this
requirement is present, either explicitly or implicitly, for the
extraction operators. It is also present explicitly in the description
-of getline (istream&, string&, charT) in section 21.3.7.9 paragraph 8.)</p>
+of getline (istream&, string&, charT) in section 21.3.7.9 <a href="lib-strings.html#lib.string.io"> [lib.string.io]</a> paragraph 8.)</p>
<p><b>Proposed resolution:</b></p>
-<p>Insert new paragraph after paragraph 2 in section 21.3.7.9 :</p>
+<p>Insert new paragraph after paragraph 2 in section 21.3.7.9 <a href="lib-strings.html#lib.string.io"> [lib.string.io]</a>:</p>
<blockquote>
<p>If the function extracts no characters, it calls
return last. This problem seems also apply to partition(), stable_partition(),
next_permutation(), and prev_permutation().</p>
<p><b>Proposed resolution:</b></p>
-<p>In 25.3.7 - Minimum and maximum, paragraphs 7 and
+<p>In 25.3.7 <a href="lib-algorithms.html#lib.alg.min.max"> [lib.alg.min.max]</a> - Minimum and maximum, paragraphs 7 and
9, append: Returns last if first==last.</p>
<p><b>Rationale:</b></p>
<p>The LWG looked in some detail at all of the above mentioned
</blockquote>
<p><b>Proposed resolution:</b></p>
<p>Change the prototypes for find(), lower_bound(), upper_bound(), and
-equal_range() in section 23.3.3 and section 23.3.4 to each have two overloads:</p>
+equal_range() in section 23.3.3 <a href="lib-containers.html#lib.set"> [lib.set]</a> and section 23.3.4 <a href="lib-containers.html#lib.multiset"> [lib.multiset]</a> to each have two overloads:</p>
<blockquote>
<pre>iterator find(const key_type & x);
const_iterator find(const key_type & x) const;</pre>
</blockquote>
<p>and the constructor that's implicitly called by the above is
defined to throw an out-of-range exception if pos > str.size(). See
-section 21.3.1 paragraph 4.</p>
+section 21.3.1 <a href="lib-strings.html#lib.string.cons"> [lib.string.cons]</a> paragraph 4.</p>
<p>On the other hand, the compare function descriptions themselves don't have
"Throws: " clauses and according to 17.3.1.3, paragraph 3, elements
"Effects" clauses correct, or are the "Throws" clauses
missing?</p>
<p><b>Proposed resolution:</b></p>
-<p>In 17.3.1.3 paragraph 3, the footnote 148 attached to
+<p>In 17.3.1.3 <a href="lib-intro.html#lib.structure.specifications"> [lib.structure.specifications]</a> paragraph 3, the footnote 148 attached to
the sentence "Descriptions of function semantics contain the
following elements (as appropriate):", insert the word
"further" so that the foot note reads:</p>
<b>Section:</b> 25.2.9 <a href="lib-algorithms.html#lib.alg.reverse"> [lib.alg.reverse]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Dave Abrahams <b>Date:</b> 21 Mar 2000</p>
<p>Shouldn't the effects say "applies iter_swap to all pairs..."?</p>
<p><b>Proposed resolution:</b></p>
-<p>In 25.2.9 , replace:</p>
+<p>In 25.2.9 <a href="lib-algorithms.html#lib.alg.reverse"> [lib.alg.reverse]</a>, replace:</p>
<blockquote>
Effects: For each non-negative integer i <= (last - first)/2,
applies swap to all pairs of iterators first + i, (last - i) - 1.
<p> Requires: Type T is CopyConstructible (20.1.3) and Assignable (23.1)</p>
</blockquote>
<hr>
+<a name="228"><h3>228. Incorrect specification of "..._byname" facets</h3></a><p>
+<b>Section:</b> 22.2 <a href="lib-locales.html#lib.locale.categories"> [lib.locale.categories]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Apr 2000</p>
+<p>The sections 22.2.1.2 <a href="lib-locales.html#lib.locale.ctype.byname"> [lib.locale.ctype.byname]</a>, 22.2.1.4 <a href="lib-locales.html#lib.locale.ctype.byname.special"> [lib.locale.ctype.byname.special]</a>,
+22.2.1.6 <a href="lib-locales.html#lib.locale.codecvt.byname"> [lib.locale.codecvt.byname]</a>, 22.2.3.2 <a href="lib-locales.html#lib.locale.numpunct.byname"> [lib.locale.numpunct.byname]</a>, 22.2.4.2 <a href="lib-locales.html#lib.locale.collate.byname"> [lib.locale.collate.byname]</a>, 22.2.5.4 <a href="lib-locales.html#lib.locale.time.put.byname"> [lib.locale.time.put.byname]</a>, 22.2.6.4 <a href="lib-locales.html#lib.locale.moneypunct.byname"> [lib.locale.moneypunct.byname]</a>, and 22.2.7.2 <a href="lib-locales.html#lib.locale.messages.byname"> [lib.locale.messages.byname]</a> overspecify the
+definitions of the "..._byname" classes by listing a bunch
+of virtual functions. At the same time, no semantics of these
+functions are defined. Real implementations do not define these
+functions because the functional part of the facets is actually
+implemented in the corresponding base classes and the constructor of
+the "..._byname" version just provides suitable date used by
+these implementations. For example, the 'numpunct' methods just return
+values from a struct. The base class uses a statically initialized
+struct while the derived version reads the contents of this struct
+from a table. However, no virtual function is defined in
+'numpunct_byname'.</p>
+
+<p>For most classes this does not impose a problem but specifically
+for 'ctype' it does: The specialization for 'ctype_byname<char>'
+is required because otherwise the semantics would change due to the
+virtual functions defined in the general version for 'ctype_byname':
+In 'ctype<char>' the method 'do_is()' is not virtual but it is
+made virtual in both 'ctype<cT>' and 'ctype_byname<cT>'.
+Thus, a class derived from 'ctype_byname<char>' can tell whether
+this class is specialized or not under the current specification:
+Without the specialization, 'do_is()' is virtual while with
+specialization it is not virtual.</p>
+<p><b>Proposed resolution:</b></p>
+<p> Change section 22.2.1.2 (lib.locale.ctype.byname) to become:</p>
+<pre> namespace std {
+ template <class charT>
+ class ctype_byname : public ctype<charT> {
+ public:
+ typedef ctype<charT>::mask mask;
+ explicit ctype_byname(const char*, size_t refs = 0);
+ protected:
+ ~ctype_byname(); // virtual
+ };
+ }</pre>
+<p> Change section 22.2.1.6 (lib.locale.codecvt.byname) to become:</p>
+<pre> namespace std {
+ template <class internT, class externT, class stateT>
+ class codecvt_byname : public codecvt<internT, externT, stateT> {
+ public:
+ explicit codecvt_byname(const char*, size_t refs = 0);
+ protected:
+ ~codecvt_byname(); // virtual
+ };
+ }
+</pre>
+<p> Change section 22.2.3.2 (lib.locale.numpunct.byname) to become:</p>
+<pre> namespace std {
+ template <class charT>
+ class numpunct_byname : public numpunct<charT> {
+ // this class is specialized for char and wchar_t.
+ public:
+ typedef charT char_type;
+ typedef basic_string<charT> string_type;
+ explicit numpunct_byname(const char*, size_t refs = 0);
+ protected:
+ ~numpunct_byname(); // virtual
+ };
+ }</pre>
+<p> Change section 22.2.4.2 (lib.locale.collate.byname) to become:</p>
+<pre> namespace std {
+ template <class charT>
+ class collate_byname : public collate<charT> {
+ public:
+ typedef basic_string<charT> string_type;
+ explicit collate_byname(const char*, size_t refs = 0);
+ protected:
+ ~collate_byname(); // virtual
+ };
+ }</pre>
+<p> Change section 22.2.5.2 (lib.locale.time.get.byname) to become:</p>
+<pre> namespace std {
+ template <class charT, class InputIterator = istreambuf_iterator<charT> >
+ class time_get_byname : public time_get<charT, InputIterator> {
+ public:
+ typedef time_base::dateorder dateorder;
+ typedef InputIterator iter_type</pre>
+<pre> explicit time_get_byname(const char*, size_t refs = 0);
+ protected:
+ ~time_get_byname(); // virtual
+ };
+ }</pre>
+<p> Change section 22.2.5.4 (lib.locale.time.put.byname) to become:</p>
+<pre> namespace std {
+ template <class charT, class OutputIterator = ostreambuf_iterator<charT> >
+ class time_put_byname : public time_put<charT, OutputIterator>
+ {
+ public:
+ typedef charT char_type;
+ typedef OutputIterator iter_type;</pre>
+<pre> explicit time_put_byname(const char*, size_t refs = 0);
+ protected:
+ ~time_put_byname(); // virtual
+ };
+ }"</pre>
+<p> Change section 22.2.6.4 (lib.locale.moneypunct.byname) to become:</p>
+<pre> namespace std {
+ template <class charT, bool Intl = false>
+ class moneypunct_byname : public moneypunct<charT, Intl> {
+ public:
+ typedef money_base::pattern pattern;
+ typedef basic_string<charT> string_type;</pre>
+<pre> explicit moneypunct_byname(const char*, size_t refs = 0);
+ protected:
+ ~moneypunct_byname(); // virtual
+ };
+ }</pre>
+<p> Change section 22.2.7.2 (lib.locale.messages.byname) to become:</p>
+<pre> namespace std {
+ template <class charT>
+ class messages_byname : public messages<charT> {
+ public:
+ typedef messages_base::catalog catalog;
+ typedef basic_string<charT> string_type;</pre>
+<pre> explicit messages_byname(const char*, size_t refs = 0);
+ protected:
+ ~messages_byname(); // virtual
+ };
+ }</pre>
+<p>Remove section 22.2.1.4 <a href="lib-locales.html#lib.locale.ctype.byname.special"> [lib.locale.ctype.byname.special]</a> completely (because in
+this case only those members are defined to be virtual which are
+defined to be virtual in 'ctype<cT>'.)</p>
+
+<p><i>[Post-Tokyo: Dietmar Kühl submitted this issue at the request of
+the LWG to solve the underlying problems raised by issue <a href="lwg-closed.html#138">138</a>.]</i></p>
+
+<p><i>[Copenhagen: proposed resolution was revised slightly, to remove
+three last virtual functions from <tt>messages_byname</tt>.]</i></p>
+
+<hr>
+<a name="230"><h3>230. Assignable specified without also specifying CopyConstructible</h3></a><p>
+<b>Section:</b> 17 <a href="lib-intro.html#lib.library"> [lib.library]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Beman Dawes <b>Date:</b> 26 Apr 2000</p>
+<p>Issue <a href="lwg-defects.html#227">227</a> identified an instance (std::swap) where
+Assignable was specified without also specifying
+CopyConstructible. The LWG asked that the standard be searched to
+determine if the same defect existed elsewhere.</p>
+
+<p>There are a number of places (see proposed resolution below) where
+Assignable is specified without also specifying
+CopyConstructible. There are also several cases where both are
+specified. For example, 26.4.1 <a href="lib-numerics.html#lib.accumulate"> [lib.accumulate]</a>.</p>
+<p><b>Proposed resolution:</b></p>
+<p>In 23.1 <a href="lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> table 65 for value_type:
+change "T is Assignable" to "T is CopyConstructible and
+Assignable"
+</p>
+
+<p>In 23.1.2 <a href="lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a> table 69 X::key_type; change
+"Key is Assignable" to "Key is
+CopyConstructible and Assignable"<br>
+</p>
+
+<p>In 24.1.2 <a href="lib-iterators.html#lib.output.iterators"> [lib.output.iterators]</a> paragraph 1, change:
+</p>
+<blockquote>
+<p> A class or a built-in type X satisfies the requirements of an
+output iterator if X is an Assignable type (23.1) and also the
+following expressions are valid, as shown in Table 73:
+</p>
+</blockquote>
+<p>to:
+</p>
+<blockquote>
+<p> A class or a built-in type X satisfies the requirements of an
+output iterator if X is a CopyConstructible (20.1.3) and Assignable
+type (23.1) and also the following expressions are valid, as shown in
+Table 73:
+</p>
+</blockquote>
+
+<p><i>[Post-Tokyo: Beman Dawes submitted this issue at the request of
+the LWG. He asks that the 25.2.4 <a href="lib-algorithms.html#lib.alg.replace"> [lib.alg.replace]</a> and 25.2.5 <a href="lib-algorithms.html#lib.alg.fill"> [lib.alg.fill]</a> changes be studied carefully, as it is not clear that
+CopyConstructible is really a requirement and may be
+overspecification.]</i></p>
+<p><b>Rationale:</b></p>
+<p>The original proposed resolution also included changes to input
+iterator, fill, and replace. The LWG believes that those changes are
+not necessary. The LWG considered some blanket statement, where an
+Assignable type was also required to be Copy Constructible, but
+decided against this because fill and replace really don't require the
+Copy Constructible property.</p>
+<hr>
+<a name="232"><h3>232. "depends" poorly defined in 17.4.3.1</h3></a><p>
+<b>Section:</b> 17.4.3.1 <a href="lib-intro.html#lib.reserved.names"> [lib.reserved.names]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Peter Dimov <b>Date:</b> 18 Apr 2000</p>
+<p>17.4.3.1/1 uses the term "depends" to limit the set of allowed
+specializations of standard templates to those that "depend on a
+user-defined name of external linkage."</p>
+<p>This term, however, is not adequately defined, making it possible to
+construct a specialization that is, I believe, technically legal according to
+17.4.3.1/1, but that specializes a standard template for a built-in type such as
+'int'.</p>
+<p>The following code demonstrates the problem:</p>
+<blockquote>
+ <pre>#include <algorithm></pre>
+ <pre>template<class T> struct X
+{
+ typedef T type;
+};</pre>
+ <pre>namespace std
+{
+ template<> void swap(::X<int>::type& i, ::X<int>::type& j);
+}</pre>
+</blockquote>
+<p><b>Proposed resolution:</b></p>
+<p>Change "user-defined name" to "user-defined
+type".</p>
+<p><b>Rationale:</b></p>
+<p>This terminology is used in section 2.5.2 and 4.1.1 of <i>The C++
+Programming Language</i>. It disallows the example in the issue,
+since the underlying type itself is not user-defined. The only
+possible problem I can see is for non-type templates, but there's no
+possible way for a user to come up with a specialization for bitset,
+for example, that might not have already been specialized by the
+implementor?</p>
+
+<p><i>[Toronto: this may be related to issue <a href="lwg-active.html#120">120</a>.]</i></p>
+
+<p><i>[post-Toronto: Judy provided the above proposed resolution and
+rationale.]</i></p>
+<hr>
<a name="234"><h3>234. Typos in allocator definition</h3></a><p>
<b>Section:</b> 20.4.1.1 <a href="lib-utilities.html#lib.allocator.members"> [lib.allocator.members]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 24 Apr 2000</p>
<p>In paragraphs 12 and 13 the effects of <tt>construct()</tt> and
<p><b>Proposed resolution:</b></p>
<p>Substitute "Returns" by "Effect".</p>
<hr>
+<a name="235"><h3>235. No specification of default ctor for reverse_iterator</h3></a><p>
+<b>Section:</b> 24.4.1.1 <a href="lib-iterators.html#lib.reverse.iterator"> [lib.reverse.iterator]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 24 Apr 2000</p>
+<p>The declaration of <tt>reverse_iterator</tt> lists a default
+constructor. However, no specification is given what this constructor
+should do.</p>
+<p><b>Proposed resolution:</b></p>
+ <p>In section 24.4.1.3.1 <a href="lib-iterators.html#lib.reverse.iter.cons"> [lib.reverse.iter.cons]</a> add the following
+ paragraph:</p>
+ <blockquote>
+ <p><tt>reverse_iterator()</tt></p>
+
+ <p>Default initializes <tt>current</tt>. Iterator operations
+ applied to the resulting iterator have defined behavior if and
+ only if the corresponding operations are defined on a default
+ constructed iterator of type <tt>Iterator</tt>.</p>
+ </blockquote>
+ <p><i>[pre-Copenhagen: Dietmar provide wording for proposed
+ resolution.]</i></p>
+<hr>
<a name="237"><h3>237. Undefined expression in complexity specification</h3></a><p>
<b>Section:</b> 23.2.2.1 <a href="lib-containers.html#lib.list.cons"> [lib.list.cons]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 24 Apr 2000</p>
<p>The complexity specification in paragraph 6 says that the complexity
<p>to become</p>
<blockquote>Linear in <i>distance(first, last)</i>.</blockquote>
<hr>
-<a name="2
43"><h3>243. <tt>get</tt> and <tt>getline</tt> when sentry reports failure</h3></a><p>
-<b>Section:</b> 27.6.1.3 <a href="lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> May 15 2000</p>
-<p>basic_istream<>::get(), and basic_istream<>::getline(),
-are unclear with respect to the behavior and side-effects of the named
-functions in case of an error.</p>
+<a name="2
38"><h3>238. Contradictory results of stringbuf initialization.</h3></a><p>
+<b>Section:</b> 27.7.1.1 <a href="lib-iostreams.html#lib.stringbuf.cons"> [lib.stringbuf.cons]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 11 May 2000</p>
+<p>In 27.7.1.1 paragraph 4 the results of calling the constructor of
+'basic_stringbuf' are said to be <tt>str() == str</tt>. This is fine
+that far but consider this code:</p>
-<p>27.6.1.3, p1 states that "... If the sentry object returns
-true, when converted to a value of type bool, the function endeavors
-to obtain the requested input..." It is not clear from this (or
-the rest of the paragraph) what precisely the behavior should be when
-the sentry ctor exits by throwing an exception or when the sentry
-object returns false. In particular, what is the number of characters
-extracted that gcount() returns supposed to be?</p>
+<pre>
+ std::basic_stringbuf<char> sbuf("hello, world", std::ios_base::openmode(0));
+ std::cout << "'" << sbuf.str() << "'\n";
+</pre>
-<p>27.6.1.3 p8 and p19 say about the effects of get() and getline():
-"... In any case, it then stores a null character (using
-charT()) into the next successive location of the array." Is not
-clear whether this sentence applies if either of the conditions above
-holds (i.e., when sentry fails).</p>
+<p>Paragraph 3 of 27.7.1.1 basically says that in this case neither
+the output sequence nor the input sequence is initialized and
+paragraph 2 of 27.7.1.2 basically says that <tt>str()</tt> either
+returns the input or the output sequence. None of them is initialized,
+ie. both are empty, in which case the return from <tt>str()</tt> is
+defined to be <tt>basic_string<cT>()</tt>.</p>
+
+<p>However, probably only test cases in some testsuites will detect this
+"problem"...</p>
<p><b>Proposed resolution:</b></p>
-<p>Add to 27.6.1.3, p1 after the sentence</p>
+<p>Remove 27.7.1.1 paragraph 4.</p>
+<p><b>Rationale:</b></p>
+<p>We could fix 27.7.1.1 paragraph 4, but there would be no point. If
+we fixed it, it would say just the same thing as text that's already
+in the standard.</p>
+<hr>
+<a name="242"><h3>242. Side effects of function objects</h3></a><p>
+<b>Section:</b> 25.2.3 <a href="lib-algorithms.html#lib.alg.transform"> [lib.alg.transform]</a>, 26.4 <a href="lib-numerics.html#lib.numeric.ops"> [lib.numeric.ops]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Angelika Langer <b>Date:</b> May 15 2000</p>
+<p>The algorithms transform(), accumulate(), inner_product(),
+partial_sum(), and adjacent_difference() require that the function
+object supplied to them shall not have any side effects.</p>
+
+<p>The standard defines a side effect in 1.9 <a href="intro.html#intro.execution"> [intro.execution]</a> as:</p>
+<blockquote>-7- Accessing an object designated by a volatile lvalue (basic.lval),
+modifying an object, calling a library I/O function, or calling a function
+that does any of those operations are all side effects, which are changes
+in the state of the execution environment.</blockquote>
+
+<p>As a consequence, the function call operator of a function object supplied
+to any of the algorithms listed above cannot modify data members, cannot
+invoke any function that has a side effect, and cannot even create and
+modify temporary objects. It is difficult to imagine a function object
+that is still useful under these severe limitations. For instance, any
+non-trivial transformator supplied to transform() might involve creation
+and modification of temporaries, which is prohibited according to the current
+wording of the standard.</p>
+
+<p>On the other hand, popular implementations of these algorithms exhibit
+uniform and predictable behavior when invoked with a side-effect-producing
+function objects. It looks like the strong requirement is not needed for
+efficient implementation of these algorithms.</p>
+
+<p>The requirement of side-effect-free function objects could be
+replaced by a more relaxed basic requirement (which would hold for all
+function objects supplied to any algorithm in the standard library):</p>
+<blockquote>A function objects supplied to an algorithm shall not invalidate
+any iterator or sequence that is used by the algorithm. Invalidation of
+the sequence includes destruction of the sorting order if the algorithm
+relies on the sorting order (see section 25.3 - Sorting and related operations
+[lib.alg.sorting]).</blockquote>
+
+<p>I can't judge whether it is intended that the function objects supplied
+to transform(), accumulate(), inner_product(), partial_sum(), or adjacent_difference()
+shall not modify sequence elements through dereferenced iterators.</p>
+
+<p>It is debatable whether this issue is a defect or a change request.
+Since the consequences for user-supplied function objects are drastic and
+limit the usefulness of the algorithms significantly I would consider it
+a defect.</p>
+<p><b>Proposed resolution:</b></p>
+
+<p><i>Things to notice about these changes:</i></p>
+
+<ol>
+<li> <i>The fully-closed ("[]" as opposed to half-closed "[)" ranges
+ are intentional. we want to prevent side-effects from
+ invalidating the end iterators.</i>
+</li>
+
+<li> <i>That has the unintentional side-effect of prohibiting
+ modification of the end element as a side-effect. This could
+ conceivably be significant in some cases.</i>
+</li>
+
+<li> <i>The wording also prevents side-effects from modifying elements
+ of the output sequence. I can't imagine why anyone would want
+ to do this, but it is arguably a restriction that implementors
+ don't need to place on users.</i>
+</li>
+
+<li> <i>Lifting the restrictions imposed in #2 and #3 above is possible
+ and simple, but would require more verbiage.</i>
+</li>
+</ol>
+
+<p>Change 25.2.3/2 from:</p>
<blockquote>
-"... If the sentry object returns true, when converted to a value of
-type bool, the function endeavors to obtain the requested input."
+ -2- Requires: op and binary_op shall not have any side effects.
</blockquote>
-<p>the following</p>
-
+<p>to:</p>
<blockquote>
-"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."
+ -2- Requires: in the ranges [first1, last1], [first2, first2 +
+ (last1 - first1)] and [result, result + (last1- first1)], op and
+ binary_op shall neither modify elements nor invalidate iterators or
+ subranges.
+ [Footnote: The use of fully closed ranges is intentional --end footnote]
+</blockquote>
+
+
+<p>Change 25.2.3/2 from:</p>
+
+<blockquote>
+ -2- Requires: op and binary_op shall not have any side effects.
+</blockquote>
+
+<p>to:</p>
+
+<blockquote>
+ -2- Requires: op and binary_op shall not invalidate iterators or
+ subranges, or modify elements in the ranges [first1, last1],
+ [first2, first2 + (last1 - first1)], and [result, result + (last1
+ - first1)].
+ [Footnote: The use of fully closed ranges is intentional --end footnote]
+</blockquote>
+
+
+<p>Change 26.4.1/2 from:</p>
+
+<blockquote>
+ -2- Requires: T must meet the requirements of CopyConstructible
+ (lib.copyconstructible) and Assignable (lib.container.requirements)
+ types. binary_op shall not cause side effects.
+</blockquote>
+
+<p>to:</p>
+
+<blockquote>
+ -2- Requires: T must meet the requirements of CopyConstructible
+ (lib.copyconstructible) and Assignable
+ (lib.container.requirements) types. In the range [first, last],
+ binary_op shall neither modify elements nor invalidate iterators
+ or subranges.
+ [Footnote: The use of a fully closed range is intentional --end footnote]
+</blockquote>
+
+<p>Change 26.4.2/2 from:</p>
+
+<blockquote>
+ -2- Requires: T must meet the requirements of CopyConstructible
+ (lib.copyconstructible) and Assignable (lib.container.requirements)
+ types. binary_op1 and binary_op2 shall not cause side effects.
+</blockquote>
+
+<p>to:</p>
+
+<blockquote>
+ -2- Requires: T must meet the requirements of CopyConstructible
+ (lib.copyconstructible) and Assignable (lib.container.requirements)
+ types. In the ranges [first, last] and [first2, first2 + (last -
+ first)], binary_op1 and binary_op2 shall neither modify elements
+ nor invalidate iterators or subranges.
+ [Footnote: The use of fully closed ranges is intentional --end footnote]
+</blockquote>
+
+
+<p>Change 26.4.3/4 from:</p>
+
+<blockquote>
+ -4- Requires: binary_op is expected not to have any side effects.
+</blockquote>
+
+<p>to:</p>
+
+<blockquote>
+ -4- Requires: In the ranges [first, last] and [result, result +
+ (last - first)], binary_op shall neither modify elements nor
+ invalidate iterators or subranges.
+ [Footnote: The use of fully closed ranges is intentional --end footnote]
+</blockquote>
+
+<p>Change 26.4.4/2 from:</p>
+
+<blockquote>
+ -2- Requires: binary_op shall not have any side effects.
+</blockquote>
+
+<p>to:</p>
+
+<blockquote>
+ -2- Requires: In the ranges [first, last] and [result, result +
+ (last - first)], binary_op shall neither modify elements nor
+ invalidate iterators or subranges.
+ [Footnote: The use of fully closed ranges is intentional --end footnote]
+</blockquote>
+
+<p><i>[Toronto: Dave Abrahams supplied wording.]</i></p>
+
+<p><i>[Copenhagen: Proposed resolution was modified slightly. Matt
+added footnotes pointing out that the use of closed ranges was
+intentional.]</i></p>
+
+<hr>
+<a name="243"><h3>243. <tt>get</tt> and <tt>getline</tt> when sentry reports failure</h3></a><p>
+<b>Section:</b> 27.6.1.3 <a href="lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> May 15 2000</p>
+<p>basic_istream<>::get(), and basic_istream<>::getline(),
+are unclear with respect to the behavior and side-effects of the named
+functions in case of an error.</p>
+
+<p>27.6.1.3, p1 states that "... If the sentry object returns
+true, when converted to a value of type bool, the function endeavors
+to obtain the requested input..." It is not clear from this (or
+the rest of the paragraph) what precisely the behavior should be when
+the sentry ctor exits by throwing an exception or when the sentry
+object returns false. In particular, what is the number of characters
+extracted that gcount() returns supposed to be?</p>
+
+<p>27.6.1.3 p8 and p19 say about the effects of get() and getline():
+"... In any case, it then stores a null character (using
+charT()) into the next successive location of the array." Is not
+clear whether this sentence applies if either of the conditions above
+holds (i.e., when sentry fails).</p>
+<p><b>Proposed resolution:</b></p>
+<p>Add to 27.6.1.3, p1 after the sentence</p>
+
+<blockquote>
+"... If the sentry object returns true, when converted to a value of
+type bool, the function endeavors to obtain the requested input."
+</blockquote>
+
+<p>the following</p>
+
+
+<blockquote>
+"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."
</blockquote>
<p><b>Rationale:</b></p>
<p>Although the general philosophy of the input functions is that the
because it was more consistent with the way eof is described for other
input facets.</p>
<hr>
+<a name="250"><h3>250. splicing invalidates iterators</h3></a><p>
+<b>Section:</b> 23.2.2.4 <a href="lib-containers.html#lib.list.ops"> [lib.list.ops]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Brian Parker <b>Date:</b> 14 Jul 2000</p>
+<p>
+Section 23.2.2.4 [lib.list.ops] states that
+</p>
+<pre>
+ void splice(iterator position, list<T, Allocator>& x);
+</pre>
+<p>
+<i>invalidates</i> all iterators and references to list <tt>x</tt>.
+</p>
+
+<p>
+This is unnecessary and defeats an important feature of splice. In
+fact, the SGI STL guarantees that iterators to <tt>x</tt> remain valid
+after <tt>splice</tt>.
+</p>
+<p><b>Proposed resolution:</b></p>
+
+<p>Add a footnote to 23.2.2.4 <a href="lib-containers.html#lib.list.ops"> [lib.list.ops]</a>, paragraph 1:</p>
+<blockquote>
+[<i>Footnote:</i> As specified in 20.1.5 <a href="lib-utilities.html#lib.allocator.requirements"> [lib.allocator.requirements]</a>, paragraphs
+4-5, the semantics described in this clause applies only to the case
+where allocators compare equal. --end footnote]
+</blockquote>
+
+<p>In 23.2.2.4 <a href="lib-containers.html#lib.list.ops"> [lib.list.ops]</a>, replace paragraph 4 with:</p>
+<blockquote>
+Effects: Inserts the contents of x before position and x becomes
+empty. Pointers and references to the moved elements of x now refer to
+those same elements but as members of *this. Iterators referring to the
+moved elements will continue to refer to their elements, but they now
+behave as iterators into *this, not into x.
+</blockquote>
+
+<p>In 23.2.2.4 <a href="lib-containers.html#lib.list.ops"> [lib.list.ops]</a>, replace paragraph 7 with:</p>
+<blockquote>
+Effects: Inserts an element pointed to by i from list x before
+position and removes the element from x. The result is unchanged if
+position == i or position == ++i. Pointers and references to *i continue
+to refer to this same element but as a member of *this. Iterators to *i
+(including i itself) continue to refer to the same element, but now
+behave as iterators into *this, not into x.
+</blockquote>
+
+<p>In 23.2.2.4 <a href="lib-containers.html#lib.list.ops"> [lib.list.ops]</a>, replace paragraph 12 with:</p>
+<blockquote>
+Requires: [first, last) is a valid range in x. The result is
+undefined if position is an iterator in the range [first, last).
+Pointers and references to the moved elements of x now refer to those
+same elements but as members of *this. Iterators referring to the moved
+elements will continue to refer to their elements, but they now behave as
+iterators into *this, not into x.
+</blockquote>
+
+<p><i>[pre-Copenhagen: Howard provided wording.]</i></p>
+<p><b>Rationale:</b></p>
+<p>The original proposed resolution said that iterators and references
+would remain "valid". The new proposed resolution clarifies what that
+means. Note that this only applies to the case of equal allocators.
+From 20.1.5 <a href="lib-utilities.html#lib.allocator.requirements"> [lib.allocator.requirements]</a> paragraph 4, the behavior of list when
+allocators compare nonequal is outside the scope of the standard.</p>
+<hr>
<a name="251"><h3>251. basic_stringbuf missing allocator_type</h3></a><p>
<b>Section:</b> 27.7.1 <a href="lib-iostreams.html#lib.stringbuf"> [lib.stringbuf]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 28 Jul 2000</p>
<p>The synopsis for the template class <tt>basic_stringbuf</tt>
<p><b>Proposed resolution:</b></p>
<p>Replace copy_event with copyfmt_event in the named paragraph.</p>
<hr>
+<a name="259"><h3>259. <tt>basic_string::operator[]</tt> and const correctness</h3></a><p>
+<b>Section:</b> 21.3.4 <a href="lib-strings.html#lib.string.access"> [lib.string.access]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Chris Newton <b>Date:</b> 27 Aug 2000</p>
+<p>
+<i>Paraphrased from a message that Chris Newton posted to comp.std.c++:</i>
+</p>
+
+<p>
+The standard's description of <tt>basic_string<>::operator[]</tt>
+seems to violate const correctness.
+</p>
+
+<p>
+The standard (21.3.4/1) says that "If <tt>pos < size()</tt>,
+returns <tt>data()[pos]</tt>." The types don't work. The
+return value of <tt>data()</tt> is <tt>const charT*</tt>, but
+<tt>operator[]</tt> has a non-const version whose return type is <tt>reference</tt>.
+</p>
+<p><b>Proposed resolution:</b></p>
+<p>
+In section 21.3.4, paragraph 1, change
+"<tt>data()[<i>pos</i>]</tt>" to "<tt>*(begin() +
+<i>pos</i>)</tt>".
+</p>
+<hr>
<a name="260"><h3>260. Inconsistent return type of <tt>istream_iterator::operator++(int)</tt>
</h3></a><p>
<b>Section:</b> 24.5.1.2 <a href="lib-iterators.html#lib.istream.iterator.ops"> [lib.istream.iterator.ops]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 27 Aug 2000</p>
or rend().
</blockquote>
<hr>
+<a name="264"><h3>264. Associative container <tt>insert(i, j)</tt> complexity requirements are not feasible.</h3></a><p>
+<b>Section:</b> 23.1.2 <a href="lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> John Potter <b>Date:</b> 07 Sep 2000</p>
+<p>
+Table 69 requires linear time if [i, j) is sorted. Sorted is necessary but not sufficient.
+Consider inserting a sorted range of even integers into a set<int> containing the odd
+integers in the same range.
+</p>
+
+<p><i>Related issue: <a href="lwg-closed.html#102">102</a></i></p>
+<p><b>Proposed resolution:</b></p>
+<p>
+In Table 69, in section 23.1.2, change the complexity clause for
+insertion of a range from "N log(size() + N) (N is the distance
+from i to j) in general; linear if [i, j) is sorted according to
+value_comp()" to "N log(size() + N), where N is the distance
+from i to j".
+</p>
+
+<p><i>[Copenhagen: Minor fix in proposed resolution: fixed unbalanced
+parens in the revised wording.]</i></p>
+
+<p><b>Rationale:</b></p>
+<p>
+Testing for valid insertions could be less efficient than simply
+inserting the elements when the range is not both sorted and between
+two adjacent existing elements; this could be a QOI issue.
+</p>
+
+<p>
+The LWG considered two other options: (a) specifying that the
+complexity was linear if [i, j) is sorted according to value_comp()
+and between two adjacent existing elements; or (b) changing to
+Klog(size() + N) + (N - K) (N is the distance from i to j and K is the
+number of elements which do not insert immediately after the previous
+element from [i, j) including the first). The LWG felt that, since
+we can't guarantee linear time complexity whenever the range to be
+inserted is sorted, it's more trouble than it's worth to say that it's
+linear in some special cases.
+</p>
+<hr>
<a name="265"><h3>265. std::pair::pair() effects overly restrictive</h3></a><p>
<b>Section:</b> 20.2.2 <a href="lib-utilities.html#lib.pairs"> [lib.pairs]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 11 Sep 2000</p>
<p>
clarified by core issue 178, and there is no longer any doubt that
the straightforward implementation is correct.</p>
<hr>
+<a name="266"><h3>266. bad_exception::~bad_exception() missing Effects clause</h3></a><p>
+<b>Section:</b> 18.6.2.1 <a href="lib-support.html#lib.bad.exception"> [lib.bad.exception]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 24 Sep 2000</p>
+<p>
+The synopsis for std::bad_exception lists the function ~bad_exception()
+but there is no description of what the function does (the Effects
+clause is missing).
+</p>
+<p><b>Proposed resolution:</b></p>
+<p>
+Remove the destructor from the class synopses of
+<tt>bad_alloc</tt> (18.4.2.1 <a href="lib-support.html#lib.bad.alloc"> [lib.bad.alloc]</a>),
+<tt>bad_cast</tt> (18.5.2 <a href="lib-support.html#lib.bad.cast"> [lib.bad.cast]</a>),
+<tt>bad_typeid</tt> (18.5.3 <a href="lib-support.html#lib.bad.typeid"> [lib.bad.typeid]</a>),
+and <tt>bad_exception</tt> (18.6.2.1 <a href="lib-support.html#lib.bad.exception"> [lib.bad.exception]</a>).
+</p>
+<p><b>Rationale:</b></p>
+<p>
+This is a general problem with the exception classes in clause 18.
+The proposed resolution is to remove the destructors from the class
+synopses, rather than to document the destructors' behavior, because
+removing them is more consistent with how exception classes are
+described in clause 19.
+</p>
+<hr>
<a name="268"><h3>268. Typo in locale synopsis</h3></a><p>
<b>Section:</b> 22.1.1 <a href="lib-locales.html#lib.locale"> [lib.locale]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 5 Oct 2000</p>
<p>The synopsis of the class std::locale in 22.1.1 contains two typos:
locale() throw();
locale(const locale& other) throw();
</pre>
+<hr>
+<a name="271"><h3>271. basic_iostream missing typedefs</h3></a><p>
+<b>Section:</b> 27.6.1.5 <a href="lib-iostreams.html#lib.iostreamclass"> [lib.iostreamclass]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 02 Nov 2000</p>
+<p>
+Class template basic_iostream has no typedefs. The typedefs it
+inherits from its base classes can't be used, since (for example)
+basic_iostream<T>::traits_type is ambiguous.
+</p>
+<p><b>Proposed resolution:</b></p>
+
+<p>Add the following to basic_iostream's class synopsis in
+27.6.1.5 <a href="lib-iostreams.html#lib.iostreamclass"> [lib.iostreamclass]</a>, immediately after <tt>public</tt>:</p>
+
+<pre>
+ // types:
+ typedef charT char_type;
+ typedef typename traits::int_type int_type;
+ typedef typename traits::pos_type pos_type;
+ typedef typename traits::off_type off_type;
+ typedef traits traits_type;
+</pre>
+<hr>
+<a name="272"><h3>272. Missing parentheses around subexpression</h3></a><p>
+<b>Section:</b> 27.4.4.3 <a href="lib-iostreams.html#lib.iostate.flags"> [lib.iostate.flags]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 02 Nov 2000</p>
+<p>
+27.4.4.3, p4 says about the postcondition of the function: If
+rdbuf()!=0 then state == rdstate(); otherwise
+rdstate()==state|ios_base::badbit.
+</p>
+
+<p>
+The expression on the right-hand-side of the operator==() needs to be
+parenthesized in order for the whole expression to ever evaluate to
+anything but non-zero.
+</p>
+<p><b>Proposed resolution:</b></p>
+<p>
+Add parentheses like so: rdstate()==(state|ios_base::badbit).
+</p>
+<hr>
+<a name="273"><h3>273. Missing ios_base qualification on members of a dependent class</h3></a><p>
+<b>Section:</b> 27 <a href="lib-iostreams.html#lib.input.output"> [lib.input.output]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 02 Nov 2000</p>
+<p>27.5.2.4.2, p4, and 27.8.1.6, p2, 27.8.1.7, p3, 27.8.1.9, p2,
+27.8.1.10, p3 refer to in and/or out w/o ios_base:: qualification.
+That's incorrect since the names are members of a dependent base
+class (14.6.2 [temp.dep]) and thus not visible.</p>
+<p><b>Proposed resolution:</b></p>
+<p>Qualify the names with the name of the class of which they are
+members, i.e., ios_base.</p>
+<hr>
+<a name="275"><h3>275. Wrong type in num_get::get() overloads</h3></a><p>
+<b>Section:</b> 22.2.2.1.1 <a href="lib-locales.html#lib.facet.num.get.members"> [lib.facet.num.get.members]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 02 Nov 2000</p>
+<p>
+In 22.2.2.1.1, we have a list of overloads for num_get<>::get().
+There are eight overloads, all of which are identical except for the
+last parameter. The overloads are:
+</p>
+<ul>
+<li> long& </li>
+<li> unsigned short& </li>
+<li> unsigned int& </li>
+<li> unsigned long& </li>
+<li> short& </li>
+<li> double& </li>
+<li> long double& </li>
+<li> void*& </li>
+</ul>
+
+<p>
+There is a similar list, in 22.2.2.1.2, of overloads for
+num_get<>::do_get(). In this list, the last parameter has
+the types:
+</p>
+<ul>
+<li> long& </li>
+<li> unsigned short& </li>
+<li> unsigned int& </li>
+<li> unsigned long& </li>
+<li> float& </li>
+<li> double& </li>
+<li> long double& </li>
+<li> void*& </li>
+</ul>
+
+<p>
+These two lists are not identical. They should be, since
+<tt>get</tt> is supposed to call <tt>do_get</tt> with exactly
+the arguments it was given.
+</p>
+<p><b>Proposed resolution:</b></p>
+<p>In 22.2.2.1.1 <a href="lib-locales.html#lib.facet.num.get.members"> [lib.facet.num.get.members]</a>, change</p>
+<pre>
+ iter_type get(iter_type in, iter_type end, ios_base& str,
+ ios_base::iostate& err, short& val) const;
+</pre>
+<p>to</p>
+<pre>
+ iter_type get(iter_type in, iter_type end, ios_base& str,
+ ios_base::iostate& err, float& val) const;
+</pre>
+<hr>
+<a name="281"><h3>281. std::min() and max() requirements overly restrictive</h3></a><p>
+<b>Section:</b> 25.3.7 <a href="lib-algorithms.html#lib.alg.min.max"> [lib.alg.min.max]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 02 Dec 2000</p>
+<p>The requirements in 25.3.7, p1 and 4 call for T to satisfy the
+requirements of <tt>LessThanComparable</tt> (20.1.2 <a href="lib-utilities.html#lib.lessthancomparable"> [lib.lessthancomparable]</a>)
+and <tt>CopyConstructible</tt> (20.1.3 <a href="lib-utilities.html#lib.copyconstructible"> [lib.copyconstructible]</a>).
+Since the functions take and return their arguments and result by
+const reference, I believe the <tt>CopyConstructible</tt> requirement
+is unnecessary.
+</p>
+<p><b>Proposed resolution:</b></p>
+<p>Remove the <tt>CopyConstructible</tt> requirement. Specifically, replace
+25.3.7, p1 with</p>
+<p>
+<b>-1- Requires:</b> Type T is <tt>LessThanComparable</tt>
+(20.1.2 <a href="lib-utilities.html#lib.lessthancomparable"> [lib.lessthancomparable]</a>).
+</p>
+<p>and replace 25.3.7, p4 with</p>
+<p>
+<b>-4- Requires:</b> Type T is <tt>LessThanComparable</tt>
+(20.1.2 <a href="lib-utilities.html#lib.lessthancomparable"> [lib.lessthancomparable]</a>).
+</p>
+<hr>
+<a name="285"><h3>285. minor editorial errors in fstream ctors</h3></a><p>
+<b>Section:</b> 27.8.1.6 <a href="lib-iostreams.html#lib.ifstream.cons"> [lib.ifstream.cons]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 31 Dec 2000</p>
+<p>27.8.1.6 <a href="lib-iostreams.html#lib.ifstream.cons"> [lib.ifstream.cons]</a>, p2, 27.8.1.9 <a href="lib-iostreams.html#lib.ofstream.cons"> [lib.ofstream.cons]</a>, p2, and
+27.8.1.12 <a href="lib-iostreams.html#lib.fstream.cons"> [lib.fstream.cons]</a>, p2 say about the effects of each constructor:
+</p>
+
+<p>... If that function returns a null pointer, calls
+<tt>setstate(failbit)</tt> (which may throw <tt>ios_base::failure</tt>).
+</p>
+
+<p>The parenthetical note doesn't apply since the ctors cannot throw an
+exception due to the requirement in 27.4.4.1 <a href="lib-iostreams.html#lib.basic.ios.cons"> [lib.basic.ios.cons]</a>, p3
+that <tt>exceptions()</tt> be initialized to <tt>ios_base::goodbit</tt>.
+</p>
+<p><b>Proposed resolution:</b></p>
+<p>
+Strike the parenthetical note from the Effects clause in each of the
+paragraphs mentioned above.
+</p>
+<hr>
+<a name="286"><h3>286. <cstdlib> requirements missing size_t typedef</h3></a><p>
+<b>Section:</b> 25.4 <a href="lib-algorithms.html#lib.alg.c.library"> [lib.alg.c.library]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Judy Ward <b>Date:</b> 30 Dec 2000</p>
+<p>
+The <cstdlib> header file contains prototypes for bsearch and
+qsort (C++ Standard section 25.4 paragraphs 3 and 4) and other
+prototypes (C++ Standard section 21.4 paragraph 1 table 49) that
+require the typedef size_t. Yet size_t is not listed in the
+<cstdlib> synopsis table 78 in section 25.4.
+</p>
+<p><b>Proposed resolution:</b></p>
+<p>
+Add the type size_t to Table 78 (section 25.4) and add
+the type size_t <cstdlib> to Table 97 (section C.2).
+</p>
+<p><b>Rationale:</b></p>
+<p>Since size_t is in <stdlib.h>, it must also be in <cstdlib>.</p>
+<hr>
+<a name="288"><h3>288. <cerrno> requirements missing macro EILSEQ</h3></a><p>
+<b>Section:</b> 19.3 <a href="lib-diagnostics.html#lib.errno"> [lib.errno]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Judy Ward <b>Date:</b> 30 Dec 2000</p>
+<p>
+ISO/IEC 9899:1990/Amendment1:1994 Section 4.3 States: "The list
+of macros defined in <errno.h> is adjusted to include a new
+macro, EILSEQ"
+</p>
+
+<p>
+ISO/IEC 14882:1998(E) section 19.3 does not refer
+to the above amendment.
+</p>
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Update Table 26 (section 19.3) "Header <cerrno> synopsis"
+and Table 95 (section C.2) "Standard Macros" to include EILSEQ.
+</p>
+<hr>
+<a name="292"><h3>292. effects of a.copyfmt (a)</h3></a><p>
+<b>Section:</b> 27.4.4.2 <a href="lib-iostreams.html#lib.basic.ios.members"> [lib.basic.ios.members]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 05 Jan 2001</p>
+<p>The Effects clause of the member function <tt>copyfmt()</tt> in
+27.4.4.2, p15 doesn't consider the case where the left-hand side
+argument is identical to the argument on the right-hand side, that is
+<tt>(this == &rhs)</tt>. If the two arguments are identical there
+is no need to copy any of the data members or call any callbacks
+registered with <tt>register_callback()</tt>. Also, as Howard Hinnant
+points out in message c++std-lib-8149 it appears to be incorrect to
+allow the object to fire <tt>erase_event</tt> followed by
+<tt>copyfmt_event</tt> since the callback handling the latter event
+may inadvertently attempt to access memory freed by the former.
+</p>
+<p><b>Proposed resolution:</b></p>
+<p>Change the Effects clause in 27.4.4.2, p15 from</p>
+
+<blockquote>
+<b>-15- Effects:</b>Assigns to the member objects of <tt>*this</tt>
+the corresponding member objects of <tt>rhs</tt>, except that...
+</blockquote>
+
+<p>to</p>
+
+<blockquote>
+<b>-15- Effects:</b>If <tt>(this == &rhs)</tt> does nothing. Otherwise
+assigns to the member objects of <tt>*this</tt> the corresponding member
+objects of <tt>rhs</tt>, except that...
+</blockquote>
+<hr>
+<a name="295"><h3>295. Is abs defined in <cmath>?</h3></a><p>
+<b>Section:</b> 26.5 <a href="lib-numerics.html#lib.c.math"> [lib.c.math]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Jens Maurer <b>Date:</b> 12 Jan 2001</p>
+<p>
+Table 80 lists the contents of the <cmath> header. It does not
+list <tt>abs()</tt>. However, 26.5, paragraph 6, which lists added
+signatures present in <cmath>, does say that several overloads
+of <tt>abs()</tt> should be defined in <cmath>.
+</p>
+<p><b>Proposed resolution:</b></p>
+<p>
+Add <tt>abs</tt> to Table 80. Also, remove the parenthetical list
+of functions "(abs(), div(), rand(), srand())" from 26.5 <a href="lib-numerics.html#lib.c.math"> [lib.c.math]</a>,
+paragraph 1.
+</p>
+
+<p><i>[Copenhagen: Modified proposed resolution so that it also gets
+rid of that vestigial list of functions in paragraph 1.]</i></p>
+
+<p><b>Rationale:</b></p>
+<p>All this DR does is fix a typo; it's uncontroversial. A
+separate question is whether we're doing the right thing in
+putting some overloads in <cmath> that we aren't also
+putting in <cstdlib>. That's issue <a href="lwg-active.html#323">323</a>.</p>
+<hr>
+<a name="297"><h3>297. const_mem_fun_t<>::argument_type should be const T*</h3></a><p>
+<b>Section:</b> 20.3.8 <a href="lib-utilities.html#lib.member.pointer.adaptors"> [lib.member.pointer.adaptors]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 6 Jan 2001</p>
+<p>The class templates <tt>const_mem_fun_t</tt> in 20.3.8, p8 and
+<tt>const_mem_fun1_t</tt>
+in 20.3.8, p9 derive from <tt>unary_function<T*, S></tt>, and
+<tt>binary_function<T*,
+A, S></tt>, respectively. Consequently, their <tt>argument_type</tt>, and
+<tt>first_argument_type</tt>
+members, respectively, are both defined to be <tt>T*</tt> (non-const).
+However, their function call member operator takes a <tt>const T*</tt>
+argument. It is my opinion that <tt>argument_type</tt> should be <tt>const
+T*</tt> instead, so that one can easily refer to it in generic code. The
+example below derived from existing code fails to compile due to the
+discrepancy:
+</p>
+
+<p>
+<tt>template <class T></tt>
+<br><tt>void foo (typename T::argument_type arg) // #1</tt>
+<br><tt>{</tt>
+<br><tt> typename T::result_type (T::*pf) (typename
+T::argument_type)
+const = // #2</tt>
+<br><tt> &T::operator();</tt>
+<br><tt>}</tt>
+</p>
+
+<p><tt>struct X { /* ... */ };</tt></p>
+
+<p>
+<tt>int main ()</tt>
+<br><tt>{</tt>
+<br><tt> const X x;</tt>
+<br><tt> foo<std::const_mem_fun_t<void, X>
+>(&x);
+// #3</tt>
+<br><tt>}</tt>
+</p>
+
+<p>#1 <tt>foo()</tt> takes a plain unqualified <tt>X*</tt> as an argument
+<br>#2 the type of the pointer is incompatible with the type of the member
+function
+<br>#3 the address of a constant being passed to a function taking a non-const
+<tt>X*</tt>
+</p>
+<p><b>Proposed resolution:</b></p>
+<p>Replace the top portion of the definition of the class template
+const_mem_fun_t in 20.3.8, p8
+</p>
+<p>
+<tt>template <class S, class T> class const_mem_fun_t</tt>
+<br><tt> : public
+unary_function<T*, S> {</tt>
+</p>
+<p>with</p>
+<p>
+<tt>template <class S, class T> class const_mem_fun_t</tt>
+<br><tt> : public
+unary_function<<b>const</b> T*, S> {</tt>
+</p>
+<p>Also replace the top portion of the definition of the class template
+const_mem_fun1_t in 20.3.8, p9</p>
+<p>
+<tt>template <class S, class T, class A> class const_mem_fun1_t</tt>
+<br><tt> : public
+binary_function<T*, A, S> {</tt>
+</p>
+<p>with</p>
+<p>
+<tt>template <class S, class T, class A> class const_mem_fun1_t</tt>
+<br><tt> : public
+binary_function<<b>const</b> T*, A, S> {</tt>
+</p>
+<p><b>Rationale:</b></p>
+<p>This is simply a contradiction: the <tt>argument_type</tt> typedef,
+and the argument type itself, are not the same.</p>
+<hr>
+<a name="298"><h3>298. ::operator delete[] requirement incorrect/insufficient</h3></a><p>
+<b>Section:</b> 18.4.1.2 <a href="lib-support.html#lib.new.delete.array"> [lib.new.delete.array]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> John A. Pedretti <b>Date:</b> 10 Jan 2001</p>
+<p>
+The default behavior of <tt>operator delete[]</tt> described in 18.4.1.2, p12 -
+namely that for non-null value of <i>ptr</i>, the operator reclaims storage
+allocated by the earlier call to the default <tt>operator new[]</tt> - is not
+correct in all cases. Since the specified <tt>operator new[]</tt> default
+behavior is to call <tt>operator new</tt> (18.4.1.2, p4, p8), which can be
+replaced, along with <tt>operator delete</tt>, by the user, to implement their
+own memory management, the specified default behavior of<tt> operator
+delete[]</tt> must be to call <tt>operator delete</tt>.
+</p>
+<p><b>Proposed resolution:</b></p>
+<p>Change 18.4.1.2, p12 from</p>
+<blockquote>
+<b>-12-</b> <b>Default behavior:</b>
+<ul>
+<li>
+For a null value of <i><tt>ptr</tt></i> , does nothing.
+</li>
+<li>
+Any other value of <i><tt>ptr</tt></i> shall be a value returned
+earlier by a call to the default <tt>operator new[](std::size_t)</tt>.
+[Footnote: The value must not have been invalidated by an intervening
+call to <tt>operator delete[](void*)</tt> (17.4.3.7 <a href="lib-intro.html#lib.res.on.arguments"> [lib.res.on.arguments]</a>).
+--- end footnote]
+For such a non-null value of <i><tt>ptr</tt></i> , reclaims storage
+allocated by the earlier call to the default <tt>operator new[]</tt>.
+</li>
+</ul>
+</blockquote>
+
+<p>to</p>
+
+<blockquote>
+<b>-12-</b> <b>Default behavior: </b>Calls <tt>operator
+delete(</tt><i>ptr</i>)
+or <tt>operator delete(<i>ptr</i>, std::nothrow)</tt> respectively.
+</blockquote>
+<p>and expunge paragraph 13.</p>
+<hr>
+<a name="301"><h3>301. basic_string template ctor effects clause omits allocator argument</h3></a><p>
+<b>Section:</b> 21.3.1 <a href="lib-strings.html#lib.string.cons"> [lib.string.cons]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 27 Jan 2001</p>
+<p>
+The effects clause for the basic_string template ctor in 21.3.1, p15
+leaves out the third argument of type Allocator. I believe this to be
+a mistake.
+</p>
+<p><b>Proposed resolution:</b></p>
+<p>Replace</p>
+
+<blockquote>
+ <p>
+<b>-15- Effects:</b> If <i><tt>InputIterator</tt></i> is an integral
+ type, equivalent to</p>
+
+ <blockquote><tt>basic_string(static_cast<size_type>(begin),
+ static_cast<value_type>(end))</tt></blockquote>
+</blockquote>
+
+<p>with</p>
+
+<blockquote>
+ <p>
+<b>-15- Effects:</b> If <i><tt>InputIterator</tt></i> is an integral
+ type, equivalent to</p>
+
+ <blockquote><tt>basic_string(static_cast<size_type>(begin),
+ static_cast<value_type>(end), <b>a</b>)</tt></blockquote>
+</blockquote>
+<hr>
+<a name="303"><h3>303. Bitset input operator underspecified</h3></a><p>
+<b>Section:</b> 23.3.5.3 <a href="lib-containers.html#lib.bitset.operators"> [lib.bitset.operators]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 5 Feb 2001</p>
+<p>
+In 23.3.5.3, we are told that <tt>bitset</tt>'s input operator
+"Extracts up to <i>N</i> (single-byte) characters from
+<i>is</i>.", where <i>is</i> is a stream of type
+<tt>basic_istream<charT, traits></tt>.
+</p>
+
+<p>
+The standard does not say what it means to extract single byte
+characters from a stream whose character type, <tt>charT</tt>, is in
+general not a single-byte character type. Existing implementations
+differ.
+</p>
+
+<p>
+A reasonable solution will probably involve <tt>widen()</tt> and/or
+<tt>narrow()</tt>, since they are the supplied mechanism for
+converting a single character between <tt>char</tt> and
+arbitrary <tt>charT</tt>.
+</p>
+
+<p>Narrowing the input characters is not the same as widening the
+literals <tt>'0'</tt> and <tt>'1'</tt>, because there may be some
+locales in which more than one wide character maps to the narrow
+character <tt>'0'</tt>. Narrowing means that alternate
+representations may be used for bitset input, widening means that
+they may not be.</p>
+
+<p>Note that for numeric input, <tt>num_get<></tt>
+(22.2.2.1.2/8) compares input characters to widened version of narrow
+character literals.</p>
+
+<p>From Pete Becker, in c++std-lib-8224:</p>
+<blockquote>
+<p>
+Different writing systems can have different representations for the
+digits that represent 0 and 1. For example, in the Unicode representation
+of the Devanagari script (used in many of the Indic languages) the digit 0
+is 0x0966, and the digit 1 is 0x0967. Calling narrow would translate those
+into '0' and '1'. But Unicode also provides the ASCII values 0x0030 and
+0x0031 for for the Latin representations of '0' and '1', as well as code
+points for the same numeric values in several other scripts (Tamil has no
+character for 0, but does have the digits 1-9), and any of these values
+would also be narrowed to '0' and '1'.
+</p>
+
+<p>...</p>
+
+<p>
+It's fairly common to intermix both native and Latin
+representations of numbers in a document. So I think the rule has to be
+that if a wide character represents a digit whose value is 0 then the bit
+should be cleared; if it represents a digit whose value is 1 then the bit
+should be set; otherwise throw an exception. So in a Devanagari locale,
+both 0x0966 and 0x0030 would clear the bit, and both 0x0967 and 0x0031
+would set it. Widen can't do that. It would pick one of those two values,
+and exclude the other one.
+</p>
+
+</blockquote>
+
+<p>From Jens Maurer, in c++std-lib-8233:</p>
+
+<blockquote>
+<p>
+Whatever we decide, I would find it most surprising if
+bitset conversion worked differently from int conversion
+with regard to alternate local representations of
+numbers.
+</p>
+
+<p>Thus, I think the options are:</p>
+<ul>
+ <li> Have a new defect issue for 22.2.2.1.2/8 so that it will
+require the use of narrow().</li>
+
+ <li> Have a defect issue for bitset() which describes clearly
+that widen() is to be used.</li>
+</ul>
+</blockquote>
+<p><b>Proposed resolution:</b></p>
+
+ <p>Replace the first two sentences of paragraph 5 with:</p>
+
+ <blockquote>
+ Extracts up to <i>N</i> characters from <i>is</i>. Stores these
+ characters in a temporary object <i>str</i> of type
+ <tt>basic_string<charT, traits></tt>, then evaluates the
+ expression <tt><i>x</i> = bitset<N>(<i>str</i>)</tt>.
+ </blockquote>
+
+ <p>Replace the third bullet item in paragraph 5 with:</p>
+ <ul><li>
+ the next input character is neither <tt><i>is</i>.widen(0)</tt>
+ nor <tt><i>is</i>.widen(1)</tt> (in which case the input character
+ is not extracted).
+ </li></ul>
+
+<p><b>Rationale:</b></p>
+<p>Input for <tt>bitset</tt> should work the same way as numeric
+input. Using <tt>widen</tt> does mean that alternative digit
+representations will not be recognized, but this was a known
+consequence of the design choice.</p>
+<hr>
+<a name="306"><h3>306. offsetof macro and non-POD types</h3></a><p>
+<b>Section:</b> 18.1 <a href="lib-support.html#lib.support.types"> [lib.support.types]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Steve Clamage <b>Date:</b> 21 Feb 2001</p>
+<p>Spliced together from reflector messages c++std-lib-8294 and -8295:</p>
+
+<p>18.1, paragraph 5, reads: "The macro <tt>offsetof</tt>
+accepts a restricted set of <i>type</i> arguments in this
+International Standard. <i>type</i> shall be a POD structure or a POD
+union (clause 9). The result of applying the offsetof macro to a field
+that is a static data member or a function member is
+undefined."</p>
+
+<p>For the POD requirement, it doesn't say "no diagnostic
+required" or "undefined behavior". I read 1.4 <a href="intro.html#intro.compliance"> [intro.compliance]</a>, paragraph 1, to mean that a diagnostic is required.
+It's not clear whether this requirement was intended. While it's
+possible to provide such a diagnostic, the extra complication doesn't
+seem to add any value.
+</p>
+<p><b>Proposed resolution:</b></p>
+<p>Change 18.1, paragraph 5, to "If <i>type</i> is not a POD
+structure or a POD union the results are undefined."</p>
+
+<p><i>[Copenhagen: straw poll was 7-4 in favor. It was generally
+agreed that requiring a diagnostic was inadvertent, but some LWG
+members thought that diagnostics should be required whenever
+possible.]</i></p>
+
+<hr>
+<a name="307"><h3>307. Lack of reference typedefs in container adaptors</h3></a><p>
+<b>Section:</b> 23.2.3 <a href="lib-containers.html#lib.container.adaptors"> [lib.container.adaptors]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Howard Hinnant <b>Date:</b> 13 Mar 2001</p>
+
+<p>From reflector message c++std-lib-8330. See also lib-8317.</p>
+
+<p>
+The standard is currently inconsistent in 23.2.3.2 <a href="lib-containers.html#lib.priority.queue"> [lib.priority.queue]</a>
+paragraph 1 and 23.2.3.3 <a href="lib-containers.html#lib.stack"> [lib.stack]</a> paragraph 1.
+23.2.3.3/1, for example, says:
+</p>
+
+<blockquote>
+-1- Any sequence supporting operations back(), push_back() and pop_back()
+can be used to instantiate stack. In particular, vector (lib.vector), list
+(lib.list) and deque (lib.deque) can be used.
+</blockquote>
+
+<p>But this is false: vector<bool> can not be used, because the
+container adaptors return a T& rather than using the underlying
+container's reference type.</p>
+
+<p>This is a contradiction that can be fixed by:</p>
+
+<ol>
+<li>Modifying these paragraphs to say that vector<bool>
+ is an exception.</li>
+<li>Removing the vector<bool> specialization.</li>
+<li>Changing the return types of stack and priority_queue to use
+ reference typedef's.</li>
+</ol>
+
+<p>
+I propose 3. This does not preclude option 2 if we choose to do it
+later (see issue <a href="lwg-active.html#96">96</a>); the issues are independent. Option
+3 offers a small step towards support for proxied containers. This
+small step fixes a current contradiction, is easy for vendors to
+implement, is already implemented in at least one popular lib, and
+does not break any code.
+</p>
+
+<p><b>Proposed resolution:</b></p>
+<p>Summary: Add reference and const_reference typedefs to queue,
+priority_queue and stack. Change return types of "value_type&" to
+"reference". Change return types of "const value_type&" to
+"const_reference". Details:</p>
+
+<p>Change 23.2.3.1/1 from:</p>
+
+<pre>
+ namespace std {
+ template <class T, class Container = deque<T> >
+ class queue {
+ public:
+ typedef typename Container::value_type value_type;
+ typedef typename Container::size_type size_type;
+ typedef Container container_type;
+ protected:
+ Container c;
+
+ public:
+ explicit queue(const Container& = Container());
+
+ bool empty() const { return c.empty(); }
+ size_type size() const { return c.size(); }
+ value_type& front() { return c.front(); }
+ const value_type& front() const { return c.front(); }
+ value_type& back() { return c.back(); }
+ const value_type& back() const { return c.back(); }
+ void push(const value_type& x) { c.push_back(x); }
+ void pop() { c.pop_front(); }
+ };
+</pre>
+
+<p>to:</p>
+
+<pre>
+ namespace std {
+ template <class T, class Container = deque<T> >
+ class queue {
+ public:
+ typedef typename Container::value_type value_type;
+ typedef typename Container::reference reference;
+ typedef typename Container::const_reference const_reference;
+ typedef typename Container::value_type value_type;
+ typedef typename Container::size_type size_type;
+ typedef Container container_type;
+ protected:
+ Container c;
+
+ public:
+ explicit queue(const Container& = Container());
+
+ bool empty() const { return c.empty(); }
+ size_type size() const { return c.size(); }
+ reference front() { return c.front(); }
+ const_reference front() const { return c.front(); }
+ reference back() { return c.back(); }
+ const_reference back() const { return c.back(); }
+ void push(const value_type& x) { c.push_back(x); }
+ void pop() { c.pop_front(); }
+ };
+</pre>
+
+<p>Change 23.2.3.2/1 from:</p>
+
+<pre>
+ namespace std {
+ template <class T, class Container = vector<T>,
+ class Compare = less<typename Container::value_type> >
+ class priority_queue {
+ public:
+ typedef typename Container::value_type value_type;
+ typedef typename Container::size_type size_type;
+ typedef Container container_type;
+ protected:
+ Container c;
+ Compare comp;
+
+ public:
+ explicit priority_queue(const Compare& x = Compare(),
+ const Container& = Container());
+ template <class InputIterator>
+ priority_queue(InputIterator first, InputIterator last,
+ const Compare& x = Compare(),
+ const Container& = Container());
+
+ bool empty() const { return c.empty(); }
+ size_type size() const { return c.size(); }
+ const value_type& top() const { return c.front(); }
+ void push(const value_type& x);
+ void pop();
+ };
+ // no equality is provided
+ }
+</pre>
+
+<p>to:</p>
+
+<pre>
+ namespace std {
+ template <class T, class Container = vector<T>,
+ class Compare = less<typename Container::value_type> >
+ class priority_queue {
+ public:
+ typedef typename Container::value_type value_type;
+ typedef typename Container::reference reference;
+ typedef typename Container::const_reference const_reference;
+ typedef typename Container::size_type size_type;
+ typedef Container container_type;
+ protected:
+ Container c;
+ Compare comp;
+
+ public:
+ explicit priority_queue(const Compare& x = Compare(),
+ const Container& = Container());
+ template <class InputIterator>
+ priority_queue(InputIterator first, InputIterator last,
+ const Compare& x = Compare(),
+ const Container& = Container());
+
+ bool empty() const { return c.empty(); }
+ size_type size() const { return c.size(); }
+ const_reference top() const { return c.front(); }
+ void push(const value_type& x);
+ void pop();
+ };
+ // no equality is provided
+ }
+</pre>
+
+<p>And change 23.2.3.3/1 from:</p>
+
+<pre>
+ namespace std {
+ template <class T, class Container = deque<T> >
+ class stack {
+ public:
+ typedef typename Container::value_type value_type;
+ typedef typename Container::size_type size_type;
+ typedef Container container_type;
+ protected:
+ Container c;
+
+ public:
+ explicit stack(const Container& = Container());
+
+ bool empty() const { return c.empty(); }
+ size_type size() const { return c.size(); }
+ value_type& top() { return c.back(); }
+ const value_type& top() const { return c.back(); }
+ void push(const value_type& x) { c.push_back(x); }
+ void pop() { c.pop_back(); }
+ };
+
+ template <class T, class Container>
+ bool operator==(const stack<T, Container>& x,
+ const stack<T, Container>& y);
+ template <class T, class Container>
+ bool operator< (const stack<T, Container>& x,
+ const stack<T, Container>& y);
+ template <class T, class Container>
+ bool operator!=(const stack<T, Container>& x,
+ const stack<T, Container>& y);
+ template <class T, class Container>
+ bool operator> (const stack<T, Container>& x,
+ const stack<T, Container>& y);
+ template <class T, class Container>
+ bool operator>=(const stack<T, Container>& x,
+ const stack<T, Container>& y);
+ template <class T, class Container>
+ bool operator<=(const stack<T, Container>& x,
+ const stack<T, Container>& y);
+ }
+</pre>
+
+<p>to:</p>
+
+<pre>
+ namespace std {
+ template <class T, class Container = deque<T> >
+ class stack {
+ public:
+ typedef typename Container::value_type value_type;
+ typedef typename Container::reference reference;
+ typedef typename Container::const_reference const_reference;
+ typedef typename Container::size_type size_type;
+ typedef Container container_type;
+ protected:
+ Container c;
+
+ public:
+ explicit stack(const Container& = Container());
+
+ bool empty() const { return c.empty(); }
+ size_type size() const { return c.size(); }
+ reference top() { return c.back(); }
+ const_reference top() const { return c.back(); }
+ void push(const value_type& x) { c.push_back(x); }
+ void pop() { c.pop_back(); }
+ };
+
+ template <class T, class Container>
+ bool operator==(const stack<T, Container>& x,
+ const stack<T, Container>& y);
+ template <class T, class Container>
+ bool operator< (const stack<T, Container>& x,
+ const stack<T, Container>& y);
+ template <class T, class Container>
+ bool operator!=(const stack<T, Container>& x,
+ const stack<T, Container>& y);
+ template <class T, class Container>
+ bool operator> (const stack<T, Container>& x,
+ const stack<T, Container>& y);
+ template <class T, class Container>
+ bool operator>=(const stack<T, Container>& x,
+ const stack<T, Container>& y);
+ template <class T, class Container>
+ bool operator<=(const stack<T, Container>& x,
+ const stack<T, Container>& y);
+ }
+</pre>
+
+<p><i>[Copenhagen: This change was discussed before the IS was released
+and it was deliberately not adopted. Nevertheless, the LWG believes
+(straw poll: 10-2) that it is a genuine defect.]</i></p>
+
+<hr>
+<a name="308"><h3>308. Table 82 mentions unrelated headers</h3></a><p>
+<b>Section:</b> 27 <a href="lib-iostreams.html#lib.input.output"> [lib.input.output]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 15 Mar 2001</p>
+<p>
+Table 82 in section 27 mentions the header <cstdlib> for String
+streams (27.7 <a href="lib-iostreams.html#lib.string.streams"> [lib.string.streams]</a>) and the headers <cstdio> and
+<cwchar> for File streams (27.8 <a href="lib-iostreams.html#lib.file.streams"> [lib.file.streams]</a>). It's not clear
+why these headers are mentioned in this context since they do not
+define any of the library entities described by the
+subclauses. According to 17.4.1.1 <a href="lib-intro.html#lib.contents"> [lib.contents]</a>, only such headers
+are to be listed in the summary.
+</p>
+<p><b>Proposed resolution:</b></p>
+<p>Remove <cstdlib> and <cwchar> from
+Table 82.</p>
+
+<p><i>[Copenhagen: changed the proposed resolution slightly. The
+original proposed resolution also said to remove <cstdio> from
+Table 82. However, <cstdio> is mentioned several times within
+section 27.8 <a href="lib-iostreams.html#lib.file.streams"> [lib.file.streams]</a>, including 27.8.2 <a href="lib-iostreams.html#lib.c.files"> [lib.c.files]</a>.]</i></p>
+
+<hr>
+<a name="312"><h3>312. Table 27 is missing headers</h3></a><p>
+<b>Section:</b> 20 <a href="lib-utilities.html#lib.utilities"> [lib.utilities]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 29 Mar 2001</p>
+<p>Table 27 in section 20 lists the header <memory> (only) for
+Memory (lib.memory) but neglects to mention the headers
+<cstdlib> and <cstring> that are discussed in 20.4.6 <a href="lib-utilities.html#lib.c.malloc"> [lib.c.malloc]</a>.</p>
+<p><b>Proposed resolution:</b></p>
+<p>Add <cstdlib> and <cstring> to Table 27, in the same row
+as <memory>.</p>
<p>----- End of document -----</p>
</body>
</html>
OSDN Git Service
