howto.html: Fix typos.

2006-12-16  Ralf Wildenhues  <Ralf.Wildenhues@gmx.de>
	
	* docs/html/27_io/howto.html: Fix typos.
	* docs/html/24_iterators/howto.html: Likewise.
	* docs/html/18_support/howto.html: Likewise.
	* docs/html/21_strings/howto.html: Likewise.
	* docs/html/ext/howto.html: Likewise.
	* docs/html/ext/ballocator_doc.html: Likewise.
	* docs/html/17_intro/porting-howto.xml: Likewise.
	* docs/html/17_intro/howto.html: Likewise.
	* docs/html/22_locale/howto.html: Likewise.
	* docs/html/faq/index.html: Likewise.
	* docs/doxygen/tables.html: Likewise.

From-SVN: r119964

11 files changed, 32 insertions, 32 deletions

diff --git a/libstdc++-v3/docs/doxygen/tables.html b/libstdc++-v3/docs/doxygen/tables.html
index 370c6ce..74ac3e2 100644
--- a/libstdc++-v3/docs/doxygen/tables.html
+++ b/libstdc++-v3/docs/doxygen/tables.html
@@ -18,7 +18,7 @@
 </p>
 
 <p>We will not try to duplicate all of the surrounding text (footnotes,
-   explanations, etc) from the standard, because that would also entail a
+   explanations, etc.) from the standard, because that would also entail a
    duplication of effort.  Some of the surrounding text has been paraphrased
    here for clarity.  If you are uncertain about the meaning or interpretation
    of these notes, consult a good textbook, and/or purchase your own copy of
@@ -589,7 +589,7 @@ examples of the latter are multiset and multimap.
 <tr>
 <td>a.clear()</td>
 <td>void</td>
-<td>erases everthing; post: size() == 0</td>
+<td>erases everything; post: size() == 0</td>
 <td>linear</td> <!-- DR 224 -->
 </tr>
 
diff --git a/libstdc++-v3/docs/html/17_intro/howto.html b/libstdc++-v3/docs/html/17_intro/howto.html
index ab65424..631e58f 100644
--- a/libstdc++-v3/docs/html/17_intro/howto.html
+++ b/libstdc++-v3/docs/html/17_intro/howto.html
@@ -189,7 +189,7 @@
    <p>We do so here, for the C++ library only.  Behavior of the compiler,
       linker, runtime loader, and other elements of &quot;the
       implementation&quot; are documented elsewhere.  Everything listed in
-      Annex B, Implemenation Qualities, are also part of the compiler, not
+      Annex B, Implementation Qualities, are also part of the compiler, not
       the library.
    </p>
    <p>For each entry, we give the section number of the standard, when
@@ -256,7 +256,7 @@
       for what does exist.
    </p>
    <p><strong>[22.*]</strong> Anything and everything we have on locale
-      implemenation will be described
+      implementation will be described
       <a href="../22_locale/howto.html">over here</a>.
    </p>
    <p><strong>[26.2.8]/9</strong> I have no idea what
diff --git a/libstdc++-v3/docs/html/17_intro/porting-howto.xml b/libstdc++-v3/docs/html/17_intro/porting-howto.xml
index cdffdcf..cea9111 100644
--- a/libstdc++-v3/docs/html/17_intro/porting-howto.xml
+++ b/libstdc++-v3/docs/html/17_intro/porting-howto.xml
@@ -363,7 +363,7 @@ o clean up the section-numbering
 	  <paramdef>int <parameter>size</parameter></paramdef>
 	</funcprototype>
       </funcsynopsis>
-      but the the signature of this constructor has changed often, and
+      but the signature of this constructor has changed often, and
       it might change again. For the current state of this, check
       <ulink url="../ext/howto.html">the howto for extensions</ulink>.
     </para>
diff --git a/libstdc++-v3/docs/html/18_support/howto.html b/libstdc++-v3/docs/html/18_support/howto.html
index eff1c75..7b1dcb8 100644
--- a/libstdc++-v3/docs/html/18_support/howto.html
+++ b/libstdc++-v3/docs/html/18_support/howto.html
@@ -125,7 +125,7 @@
    <h3><code>&lt;limits&gt;</code></h3>
    <p>This header mainly defines traits classes to give access to various
    implementation defined-aspects of the fundamental types.  The
-   traits classes -- fourteen in total -- are all specilizations of the 
+   traits classes -- fourteen in total -- are all specializations of the 
    template class <code>numeric_limits</code>, documented
    <a href="http://gcc.gnu.org/onlinedocs/libstdc++/latest-doxygen/structstd_1_1numeric__limits.html">here</a>
    and defined as follows:
diff --git a/libstdc++-v3/docs/html/21_strings/howto.html b/libstdc++-v3/docs/html/21_strings/howto.html
index ed2e743..a356667 100644
--- a/libstdc++-v3/docs/html/21_strings/howto.html
+++ b/libstdc++-v3/docs/html/21_strings/howto.html
@@ -133,7 +133,7 @@
          <li>Microsoft ships the source to CString (in the files
              MFC\SRC\Str{core,ex}.cpp), so you could fix the allocation
              bug and rebuild your MFC libraries.
-             <em><strong>Note:</strong> It looks like the the CString shipped
+             <em><strong>Note:</strong> It looks like the CString shipped
              with VC++6.0 has fixed this, although it may in fact have been
              one of the VC++ SPs that did it.</em>
          </li>
@@ -252,7 +252,7 @@
       <code>ls.size()</code> will return how many tokens there were.
    </p>
    <p>As always, there is a price paid here, in that stringtok is not
-      as fast as strtok.  The other benefits usually outweight that, however.
+      as fast as strtok.  The other benefits usually outweigh that, however.
       <a href="stringtok_std_h.txt">Another version of stringtok is given
       here</a>, suggested by Chris King and tweaked by Petr Prikryl,
       and this one uses the
diff --git a/libstdc++-v3/docs/html/22_locale/howto.html b/libstdc++-v3/docs/html/22_locale/howto.html
index 30e1e1f..3d19bb6 100644
--- a/libstdc++-v3/docs/html/22_locale/howto.html
+++ b/libstdc++-v3/docs/html/22_locale/howto.html
@@ -137,7 +137,7 @@
       Fine, you asked for it...)
    </p>
    <p>The task of changing the case of a letter or classifying a character
-      as numeric, graphical, etc, all depends on the cultural context of the
+      as numeric, graphical, etc., all depends on the cultural context of the
       program at runtime.  So, first you must take the portability question
       into account.  Once you have localized the program to a particular
       natural language, only then can you perform the specific task.
diff --git a/libstdc++-v3/docs/html/24_iterators/howto.html b/libstdc++-v3/docs/html/24_iterators/howto.html
index e4d557d..43d199d 100644
--- a/libstdc++-v3/docs/html/24_iterators/howto.html
+++ b/libstdc++-v3/docs/html/24_iterators/howto.html
@@ -67,7 +67,7 @@
       things as it would be doing if you had hand-coded it yourself (for
       the 273rd time).
    </p>
-   <p>How much overhead <em>is</em> there when using an interator class?
+   <p>How much overhead <em>is</em> there when using an iterator class?
       Very little.  Most of the layering classes contain nothing but
       typedefs, and typedefs are &quot;meta-information&quot; that simply
       tell the compiler some nicknames; they don't create code.  That
diff --git a/libstdc++-v3/docs/html/27_io/howto.html b/libstdc++-v3/docs/html/27_io/howto.html
index a9a3bbe..1472053 100644
--- a/libstdc++-v3/docs/html/27_io/howto.html
+++ b/libstdc++-v3/docs/html/27_io/howto.html
@@ -102,13 +102,13 @@
       blank lines and only &quot;Thequickbrownfox...&quot;.  With
       libraries that do not define that operator, IN (or one of IN's
       member pointers) sometimes gets converted to a void*, and the output
-      file then contains a perfect text representation of a hexidecimal
+      file then contains a perfect text representation of a hexadecimal
       address (quite a big surprise).  Others don't compile at all.
    </p>
    <p>Also note that none of this is specific to o<b>*f*</b>streams. 
       The operators shown above are all defined in the parent 
       basic_ostream class and are therefore available with all possible
-      descendents.
+      descendants.
    </p>
    <p>Return <a href="#top">to top of page</a> or
       <a href="../faq/index.html">to the FAQ</a>.
@@ -569,7 +569,7 @@
       be built and included in libstdc++.
    </p>
    <h3>Alternatives</h3>
-   <p>Don't forget that other cstdio implemenations are possible.  You could
+   <p>Don't forget that other cstdio implementations are possible.  You could
       easily write one to perform your own forms of locking, to solve your
       &quot;interesting&quot; problems.
    </p>
@@ -643,7 +643,7 @@
       interfaces, then you only need to use the appropriate interface header.
    </p>
    <p><strong>&lt;iomanip&gt;</strong> provides &quot;extractors and inserters
-      that alter information maintained by class ios_base and its dervied
+      that alter information maintained by class ios_base and its derived
       classes,&quot; such as std::setprecision and std::setw.  If you need
       to write expressions like <code>os &lt;&lt; setw(3);</code> or
       <code>is &gt;&gt; setbase(8);</code>, you must include &lt;iomanip&gt;.
diff --git a/libstdc++-v3/docs/html/ext/ballocator_doc.html b/libstdc++-v3/docs/html/ext/ballocator_doc.html
index 7b1f4d2..fa09584 100644
--- a/libstdc++-v3/docs/html/ext/ballocator_doc.html
+++ b/libstdc++-v3/docs/html/ext/ballocator_doc.html
@@ -40,7 +40,7 @@ will double every time the bitmapped allocator runs out of memory.<br>
 <hr style="width: 100%; height: 2px;"><br>
 The macro __GTHREADS decides whether to use Mutex Protection around
 every allocation/deallocation. The state of the macro is picked up
-automatically from the gthr abstration layer.<br>
+automatically from the gthr abstraction layer.<br>
 <br>
 <hr style="width: 100%; height: 2px;">
 <h3 style="text-align: center;">What is the Free List Store?</h3>
@@ -125,11 +125,11 @@ operator new.<br>
 Suppose n == 1, then the allocator does the following:<br>
 <br>
 <ol>
-  <li>Checks to see whether the a free block exists somewhere in a
+  <li>Checks to see whether a free block exists somewhere in a
 region of memory close to the last satisfied request. If so, then that
 block is marked as allocated in the bit map and given to the user. If
 not, then (2) is executed.</li>
-  <li>Is there a free block anywhere after the current block right upto
+  <li>Is there a free block anywhere after the current block right up to
 the end of the memory that we have? If so, that block is found, and the
 same procedure is applied as above, and returned to the user. If not,
 then (3) is executed.</li>
@@ -275,7 +275,7 @@ which is 8-bytes, or 2 x sizeof(size_t).<br>
 Another issue would be whether to keep the all bitmaps in a separate
 area in memory, or to keep them near the actual blocks that will be
 given out or allocated for the client. After some testing, I've decided
-to keep these bitmaps close to the actual blocks. this will help in 2
+to keep these bitmaps close to the actual blocks. This will help in 2
 ways. <br>
 <br>
 <ol>
@@ -310,7 +310,7 @@ some linear/logarithmic complexity components in it. Thus, to try and
 minimize them would be a good thing to do at the cost of a little bit
 of memory.<br>
 <br>
-Another thing to be noted is the the pool size will double every time
+Another thing to be noted is the pool size will double every time
 the internal pool gets exhausted, and all the free blocks have been
 given away. The initial size of the pool would be sizeof(size_t) x 8
 which is the number of bits in an integer, which can fit exactly
@@ -348,7 +348,7 @@ bitmap is a multiple of 32 in size. If there are 32 x (2^3) blocks of
 single objects to be given, there will be '32 x (2^3)' bits present.
 Each
 32 bits managing the allocated / free status for 32 blocks. Since each
-size_t contains 32-bits, one size_t can manage upto 32
+size_t contains 32-bits, one size_t can manage up to 32
 blocks' status. Each bit-map is made up of a number of size_t,
 whose exact number for a super-block of a given size I have just
 mentioned.<br>
@@ -364,19 +364,19 @@ field indicates free, while a 0 indicates allocated. This lets us check
 32 bits at a time to check whether there is at lease one free block in
 those 32 blocks by testing for equality with (0). Now, the allocate
 function will given a memory block find the corresponding bit in the
-bitmap, and will reset it (ie. make it re-set (0)). And when the
+bitmap, and will reset it (i.e., make it re-set (0)). And when the
 deallocate function is called, it will again set that bit after
 locating it to indicate that that particular block corresponding to
 this bit in the bit-map is not being used by anyone, and may be used to
 satisfy future requests.<br>
 <br>
-eg: Consider a bit-map of 64-bits as represented below:<br>
+e.g.: Consider a bit-map of 64-bits as represented below:<br>
 1111111111111111111111111111111111111111111111111111111111111111<br>
 <br>
 Now, when the first request for allocation of a single object comes
 along, the first block in address order is returned. And since the
 bit-maps in the reverse order to that of the address order, the last
-bit(LSB if the bit-map is considered as a binary word of 64-bits) is
+bit (LSB if the bit-map is considered as a binary word of 64-bits) is
 re-set to 0.<br>
 <br>
 The bit-map now looks like this:<br>
@@ -400,7 +400,7 @@ Where,<br>
 k =&gt; The constant overhead per node. eg. for list, it is 8 bytes,
 and for map it is 12 bytes.<br>
 c =&gt; The size of the base type on which the map/list is
-instantiated. Thus, suppose the the type1 is int and type2 is double,
+instantiated. Thus, suppose the type1 is int and type2 is double,
 they are related by the relation sizeof(double) == 2*sizeof(int). Thus,
 all types must have this double size relation for this formula to work
 properly.<br>
diff --git a/libstdc++-v3/docs/html/ext/howto.html b/libstdc++-v3/docs/html/ext/howto.html
index 800f286..888591a 100644
--- a/libstdc++-v3/docs/html/ext/howto.html
+++ b/libstdc++-v3/docs/html/ext/howto.html
@@ -387,7 +387,7 @@
         <em>operator&gt;&gt;(istream&amp;, string&amp;) doesn't set failbit</em>
     </dt>
     <dd>If nothing is extracted into the string, <code>op&gt;&gt;</code> now
-        sets <code>failbit</code> (which can cause an exception, etc, etc).
+        sets <code>failbit</code> (which can cause an exception, etc., etc.).
     </dd>
 
     <dt><a href="lwg-defects.html#214">214</a>:
diff --git a/libstdc++-v3/docs/html/faq/index.html b/libstdc++-v3/docs/html/faq/index.html
index 48f11c0..3c907be 100644
--- a/libstdc++-v3/docs/html/faq/index.html
+++ b/libstdc++-v3/docs/html/faq/index.html
@@ -250,7 +250,7 @@ which is no longer available, thanks deja...-->
          in the implementation, however handy they are.  (The extensions
          provided in the SGI STL aren't maintained by us and don't get
          a lot of our attention, because they don't require a lot of our
-         time.)  It is entirely plausable that the &quot;useful stuff&quot;
+         time.)  It is entirely plausible that the &quot;useful stuff&quot;
          from libg++ might be extracted into an updated utilities library,
          but nobody has started such a project yet.
       </p>
@@ -504,7 +504,7 @@ which is no longer available, thanks deja...-->
       <p>These macros are typically used in C library headers, guarding new
          versions of functions from their older versions.  The C++ standard
          library includes the C standard library, but it requires the C90
-         version, which for backwards-compatability reasons is often not the
+         version, which for backwards-compatibility reasons is often not the
          default for many vendors.
       </p>
       <p>More to the point, the C++ standard requires behavior which is only
@@ -592,7 +592,7 @@ which is no longer available, thanks deja...-->
 
 <hr />
 <h1><a name="4_0">4.0 Known Bugs and Non-Bugs</a></h1>
-   <em>Note that this section can get rapdily outdated -- such is the
+   <em>Note that this section can get rapidly outdated -- such is the
        nature of an open-source project.  For the latest information, join
        the mailing list or look through recent archives.   The RELEASE-
        NOTES and BUGS files are generally kept up-to-date.</em>
@@ -1006,10 +1006,10 @@ http://clisp.cons.org/~haible/gccinclude-glibc-2.2-compat.diff
       </p>
 
       <p><strong>Function objects - Complete -</strong>
-         Function return types (i.e, result_of), the functions template
+         Function return types (i.e., result_of), the functions template
 	 mem_fn (a generalization of mem_fun and mem_fun_red), function
-	 object binders (e.g, bind, a generalization of bind1st and bind2nd),
-	 and polymorhpic function wrappers (e.g, class template function).
+	 object binders (e.g., bind, a generalization of bind1st and bind2nd),
+	 and polymorphic function wrappers (e.g, class template function).
       </p>
 
       <p><strong>Type traits - Complete -</strong>
@@ -1019,7 +1019,7 @@ http://clisp.cons.org/~haible/gccinclude-glibc-2.2-compat.diff
       </p>
 
       <p><strong>A random number engine - Complete -</strong>
-         This library contains randow number generators with several different
+         This library contains random number generators with several different
 	 choices of distribution.
       </p>