diff mbox

[4/5] Fix typos in libstdc++.

Message ID 20130723104529.GC6395@domone.kolej.mff.cuni.cz
State New
Headers show

Commit Message

Ondřej Bílka July 23, 2013, 10:45 a.m. UTC
Hi, this is next in series of typo fixing patches. 

I cleaned up http://kam.mff.cuni.cz/~ondra/gcc_misspells and fixed misspells
for letters a-d. I combined this list with what I done previously and here is result.

I according to Joseph suggestion split it by directory.
This is done with following two scripts.

https://github.com/neleai/stylepp/tree/master/maintained/gcc/split_patch
https://github.com/neleai/stylepp/tree/master/maintained/gcc/prepare_patch

To simplify review I added stylepp_strip_diff tool. It takes a diff and displays 
them in compact way. Here you often fix same typo ten times which is much easier to check
when you have them next to each other.

-will be acceptible in many algorithms taking <tt>Regular</tt> values, it is not
-appopriate for this specific API and we need a less refined constraint.
+will be acceptable in many algorithms taking <tt>Regular</tt> values, it is not
+appropriate for this specific API and we need a less refined constraint.

                                       -Ammend D.12.1 [auto.ptr]p2:
                                       +Amend D.12.1 [auto.ptr]p2:
                                        ^^
                                       -Ammend [list.capacity] p1:
                                       +Amend [list.capacity] p1:
                                        ^^
                                       -Ammend in both:<br>
                                       +Amend in both:<br>
                                        ^^
                                       -Ammend p3 Freestanding implementations 17.6.1.3 [compliance]
                                       +Amend p3 Freestanding implementations 17.6.1.3 [compliance]
                                        ^^
                                       -Ammend the tuple class template declaration in 20.4.2 [tuple.tuple] as
                                       +Amend the tuple class template declaration in 20.4.2 [tuple.tuple] as
                                        ^^
                                       -Initialisation of atomics:
                                       +Initialization of atomics:
                                        ^       ^
                                -    // Remeber the PID for the process that created the semaphore set
                                +    // Remember the PID for the process that created the semaphore set
                                        ^   ^
ressions should be well-formed, even in absense of access:
ressions should be well-formed, even in absence of access:
                                        ^    ^
             -member function and other acessors return the stored value as a <tt>void*</tt>.
             +member function and other accesors return the stored value as a <tt>void*</tt>.
                                        ^  ^
to Review.  Unfortunately the issue was accidently
to Review.  Unfortunately the issue was accidentally
                                        ^        ^
got <tt>swap</tt> for <tt>pair</tt> but accidently
got <tt>swap</tt> for <tt>pair</tt> but accidentally
                                        ^        ^
ects.html#541">LWG 541</a> for how this accidently
ects.html#541">LWG 541</a> for how this accidentally
                                        ^        ^
 issue was voted to WP in Bellevue, but accidently got stepped on by
 issue was voted to WP in Bellevue, but accidentally got stepped on by
                                        ^        ^
  We do not want to be in a position of accidently introducing this
  We do not want to be in a position of accidentally introducing this
                                        ^        ^
r type.  I believe this restriction was accidently removed
r type.  I believe this restriction was accidentally removed
                                        ^        ^
1.2 [func.bind.bind]/p3, p6 and p7 were accidently removed from N2798.
1.2 [func.bind.bind]/p3, p6 and p7 were accidentally removed from N2798.
                                        ^        ^
 - * resized to a value which it cannot accomodate at runtime. Illegal
 + * resized to a value which it cannot accommodate at runtime. Illegal
                                        ^   ^
      -purpose without complications to accomodate other uses:
      +purpose without complications to accommodate other uses:
                                        ^   ^
empting to engineer <tt>forward</tt> to accomodate uses other than perfect
empting to engineer <tt>forward</tt> to accommodate uses other than perfect
                                        ^   ^
           -      type</ins> capable of accomodating 32-bit quantities.  
           +      type</ins> capable of accommodating 32-bit quantities.  
                                        ^   ^
                   -        contributor acknowledgements and/or dedications given therein.
                   +        contributor acknowledgments and/or dedications given therein.
                                        ^        ^
        -2010-11-03 Daniel comments and adjustes the currently proposed wording changes:
        +2010-11-03 Daniel comments and adjusts the currently proposed wording changes:
                                        ^    ^
                    -all the other heap alogorithms.  The should be called out in the
                    +all the other heap algorithms.  The should be called out in the
                                        ^^
                           -dynamically allcoated memory, passing ownership of dynamically allocated
                           +dynamically allocated memory, passing ownership of dynamically allocated
                                        ^   ^
                  -Bellevue: Wording is aleady present in various standards, and no-one has come forward with wording.
                  +Bellevue: Wording is already present in various standards, and no-one has come forward with wording.
                                        ^ ^
                                -const, althought they are not member functions, and are not specified as
                                +const, although they are not member functions, and are not specified as
                                        ^      ^
                                       -ammend the constructor
                                       +amend the constructor
                                        ^^
                                       -ammend the constructor 
                                       +amend the constructor 
                                        ^^
uld.  Comments inside macros written in ancilliary
uld.  Comments inside macros written in ancillary
                                        ^    ^
tside</em></span> our own macros in the ancilliary
tside</em></span> our own macros in the ancillary
                                        ^    ^
lines just vanish.  Since the macros in ancilliary
lines just vanish.  Since the macros in ancillary
                                        ^    ^
                              -   * the apprpriate cast to/from the custom pointer class so long as that
                              +   * the appropriate cast to/from the custom pointer class so long as that
                                        ^   ^
                             -b) Add an appropiate paragraph similar to resolved 25 [lib.algorithms],
                             +b) Add an appropriate paragraph similar to resolved 25 [lib.algorithms],
                                        ^     ^
             -appears to be entirely an artefact of the concepts wording.
             +appears to be entirely an artifact of the concepts wording.
                                        ^  ^
    -problem. It should be used for the assignemnt operator, as with the
    +problem. It should be used for the assignment operator, as with the
                                        ^      ^
                               -Missing assignemnt operator:
                               +Missing assignment operator:
                                        ^      ^
ators is considered as QoI, because the assigments wouldn't be
ators is considered as QoI, because the assignments wouldn't be
                                        ^    ^
-So as the decision was made on a wrong asumption, I propose to re-open
+So as the decision was made on a wrong assumption, I propose to re-open
                                        ^^
               -       // making future attemps less relevant. So we copy it before to
               +       // making future attempts less relevant. So we copy it before to
                                        ^     ^
                                     -  becuase a valid iterator is one that is known to be nonsingular.
                                     +  because a valid iterator is one that is known to be nonsingular.
                                        ^   ^
 constructor is a more serious problem, becuase failure
 constructor is a more serious problem, because failure
                                        ^   ^
          -<p>This change is reasonable becuase it clarifies the intent of this
          +<p>This change is reasonable because it clarifies the intent of this
                                        ^   ^
                              -wording, becaue the new wording requires it.
                              +wording, because the new wording requires it.
                                        ^    ^
       -Last but not least, the current behvaior is not only confusing to the casual
       +Last but not least, the current behavior is not only confusing to the casual
                                        ^   ^
the longer names allow capabilities and behaviours
the longer names allow capabilities and behaviors
                                        ^     ^
                                  -  // behaviours and guarantees of containers and algorithms defined in
                                  +  // behaviors and guarantees of containers and algorithms defined in
                                        ^     ^
                                       -behaviours.
                                       +behaviors.
                                        ^     ^
 is a naive algorithm.  It suffers from cancelling.
 is a naive algorithm.  It suffers from canceling.
                                        ^   ^
                                       -catagories. I recommend to say instead that each container::iterator shall satisfy (and thus may refine) the forward 
                                       +categories. I recommend to say instead that each container::iterator shall satisfy (and thus may refine) the forward 
                                        ^  ^
My opinion is that was not meant by the comitee to
My opinion is that was not meant by the committee to
                                        ^    ^
                                     -A comparision of the N2461 header <tt>&lt;complex&gt;</tt> synopsis ([complex.syn])
                                     +A comparison of the N2461 header <tt>&lt;complex&gt;</tt> synopsis ([complex.syn])
                                        ^      ^
cifies <tt>error_category</tt> equality comparsions based on
cifies <tt>error_category</tt> equality comparisons based on
                                        ^      ^
                   -     C++11, various compability files for shared and static
                   +     C++11, various compatibility files for shared and static
                                        ^     ^
                             -to ensure compatibity from both sides.
                             +to ensure compatibility from both sides.
                                        ^        ^
                                 -   *  compatibilty with a C interface, this allows different
                                 +   *  compatibility with a C interface, this allows different
                                        ^         ^
ode>, and <code>_Decimal128</code>, for compatibilty with the C programming language.</del>
ode>, and <code>_Decimal128</code>, for compatibility with the C programming language.</del>
                                        ^         ^
sociative.reqmts] table 69, the runtime comlexity
sociative.reqmts] table 69, the runtime complexity
                                        ^  ^
t>. This was intentionally fixed during conceptification,
t>. This was intentionally fixed during conceptualization,
                                        ^          ^
  -  was that library implementors were concerened about implementation
  +  was that library implementors were concerned about implementation
                                        ^    ^
                                -lock's constuction.
                                +lock's construction.
                                        ^    ^
             -<tt>explicit</tt> default contructor is defined in <tt>std::function</tt>.
             +<tt>explicit</tt> default constructor is defined in <tt>std::function</tt>.
                                        ^  ^
<a name="1350"></a>1350. [FCD] Implicit contructors accidentally made some library types move-only</h3>
<a name="1350"></a>1350. [FCD] Implicit constructors accidentally made some library types move-only</h3>
                                        ^  ^
                              -simply a conventient shorthand to factor common semantics into a single
                              +simply a convenient shorthand to factor common semantics into a single
                                        ^    ^
Tricks</a> wiki page has information on customising the
Tricks</a> wiki page has information on customizing the
                                        ^      ^
rd, rather than the 'region of storage' definiton in
rd, rather than the 'region of storage' definition in
                                        ^      ^
                               -Add new defintions to 17.3 [definitions]:
                               +Add new definitions to 17.3 [definitions]:
                                        ^    ^
le 37, in 21.2.1 [char.traits.require], descibes char_traits::assign
le 37, in 21.2.1 [char.traits.require], describes char_traits::assign
                                        ^   ^
 a minimum an object is declared and is destuctible.
 a minimum an object is declared and is destructible.
                                        ^   ^
                                       -diagnosable semantic rules, which means that... "a conforming
                                       +diagnostible semantic rules, which means that... "a conforming
                                        ^       ^
                    -move clause 18.8.2 diectly to Annex D.
                    +move clause 18.8.2 directly to Annex D.
                                        ^ ^
on. Is it possible to implement this as efficently as
on. Is it possible to implement this as efficiently as
                                        ^    ^
                                  -     facilites, which might be undesirable in a low-memory environment or
                                  +     facilities, which might be undesirable in a low-memory environment or
                                        ^      ^
                              -reserved identifers are in 17.6.3.3 [reserved.names], which are a
                              +reserved identifiers are in 17.6.3.3 [reserved.names], which are a
                                        ^      ^
                                       -imaginery complex number.  With the French locale it parses as a
                                       +imaginary complex number.  With the French locale it parses as a
                                        ^     ^
 -enumeration type <tt>posix_errno</tt> immediatly in the namespace <tt>std</tt>. One of
 +enumeration type <tt>posix_errno</tt> immediately in the namespace <tt>std</tt>. One of
                                        ^       ^
                                       -initialisation write might be non-atomic and hence give rise to a data
                                       +initialization write might be non-atomic and hence give rise to a data
                                        ^       ^
                                       -initialisation write, but that this need not happens-before all the
                                       +initialization write, but that this need not happens-before all the
                                        ^       ^
                                       -initialisation. What have I overlooked here?
                                       +initialization. What have I overlooked here?
                                        ^       ^
                                     -  jsut after the signature.  We need to talk to the Project Editor
                                     +  just after the signature.  We need to talk to the Project Editor
                                        ^ ^
 although remain concerned about header organisation.
 although remain concerned about header organization.
                                        ^     ^
    -unordered associative container is parameterized [..] by a function object Hash
    +unordered associative container is parametrized [..] by a function object Hash
                                        ^     ^
                 -    with the STL type parameterized allocators, we do not need to
                 +    with the STL type parametrized allocators, we do not need to
                                        ^     ^
              -   * The class %regex is parameterized around a set of related types and
              +   * The class %regex is parametrized around a set of related types and
                                        ^     ^
Each unordered associative container is parameterized by <tt>Key</tt>, by a
Each unordered associative container is parametrized by <tt>Key</tt>, by a
                                        ^     ^
Each unordered associative container is parameterized by <tt>Key</tt>, by a
Each unordered associative container is parametrized by <tt>Key</tt>, by a
                                        ^     ^
Each unordered associative container is parameterized by <tt>Key</tt>, by a
Each unordered associative container is parametrized by <tt>Key</tt>, by a
                                        ^     ^
Each unordered associative container is parameterized by <tt>Key</tt>, by a 
Each unordered associative container is parametrized by <tt>Key</tt>, by a 
                                        ^     ^
 describing the underlying memory pool, parameterized on
 describing the underlying memory pool, parametrized on
                                        ^     ^
       -2 Each associative container is parameterized on <tt>Key</tt> and an ordering
       +2 Each associative container is parametrized on <tt>Key</tt> and an ordering
                                        ^     ^
         -Each associative container is parameterized on <tt>Key</tt> and an ordering
         +Each associative container is parametrized on <tt>Key</tt> and an ordering
                                        ^     ^
       -2 Each associative container is parameterized on <tt>Key</tt> and an ordering
       +2 Each associative container is parametrized on <tt>Key</tt> and an ordering
                                        ^     ^
                -Each container type is parameterized on a @c Key type, a @c Hash type
                +Each container type is parametrized on a @c Key type, a @c Hash type
                                        ^     ^
                -Each container type is parameterized on a @c Key type, and an ordering
                +Each container type is parametrized on a @c Key type, and an ordering
                                        ^     ^
p_counted_*</code> classes, this one is parameterized on the
p_counted_*</code> classes, this one is parametrized on the
                                        ^     ^
                   -which is a template parameterized on the enum
                   +which is a template parametrized on the enum
                                        ^     ^
          -The base of the hierarchy is parameterized on the lock policy (see below.)
          +The base of the hierarchy is parametrized on the lock policy (see below.)
                                        ^     ^
                                       -parameterized on the lock policy, right up to
                                       +parametrized on the lock policy, right up to
                                        ^     ^
                           -      it is parameterized on the type of the characters which it holds.
                           +      it is parametrized on the type of the characters which it holds.
                                        ^     ^
                       -as an algorithm parameterized over the number of bits <tt>W</tt>. I doubt whether the given generalization 
                       +as an algorithm parametrized over the number of bits <tt>W</tt>. I doubt whether the given generalization 
                                        ^     ^
                                  -// a parameterized type, data members are public, etc.).
                                  +// a parametrized type, data members are public, etc.).
                                        ^     ^
      -need for the axiom to be further parameterized, and so the axiom can be
      +need for the axiom to be further parametrized, and so the axiom can be
                                        ^     ^
            -    the allocator has been parameterized. Thus, close to optimal
            +    the allocator has been parametrized. Thus, close to optimal
                                        ^     ^
                               -This is particularily vicious, as it will appear to work in almost all
                               +This is particularly vicious, as it will appear to work in almost all
                                        ^        ^
// Compile time constant that indicates prefered locking policy in
// Compile time constant that indicates preferred locking policy in
                                        ^    ^
                  -        condition to propogate deadlock detection by the host OS.</p>
                  +        condition to propagate deadlock detection by the host OS.</p>
                                        ^   ^
ver, the rationale in the issue already recognises that the
ver, the rationale in the issue already recognizes that the
                                        ^      ^
                              -Alisdair recognises this is clearly a bug introduced by some wording he
                              +Alisdair recognizes this is clearly a bug introduced by some wording he
                                        ^      ^
added consciously for clarity and is in resemblence with current
added consciously for clarity and is in resemblance with current
                                        ^      ^
                                       -througout this loop, absence of the stability requirement could
                                       +throughout this loop, absence of the stability requirement could
                                        ^     ^

Comments

Paolo Carlini July 23, 2013, 11:16 a.m. UTC | #1
Hi,

spotted a few debatable items.

On 07/23/2013 12:45 PM, Ondřej Bílka wrote:
>                                         -Ammend D.12.1 [auto.ptr]p2:
>                                         +Amend D.12.1 [auto.ptr]p2:
>                                          ^^
>                                         -Ammend [list.capacity] p1:
>                                         +Amend [list.capacity] p1:
>                                          ^^
>                                         -Ammend in both:<br>
>                                         +Amend in both:<br>
>                                          ^^
>                                         -Ammend p3 Freestanding implementations 17.6.1.3 [compliance]
>                                         +Amend p3 Freestanding implementations 17.6.1.3 [compliance]
>                                          ^^
>                                         -Ammend the tuple class template declaration in 20.4.2 [tuple.tuple] as
>                                         +Amend the tuple class template declaration in 20.4.2 [tuple.tuple] as
>                                          ^^
>                                         -Initialisation of atomics:
>                                         +Initialization of atomics:
>                                          ^       ^
>                                  -    // Remeber the PID for the process that created the semaphore set
>                                  +    // Remember the PID for the process that created the semaphore set
>                                          ^   ^
> ressions should be well-formed, even in absense of access:
> ressions should be well-formed, even in absence of access:
>                                          ^    ^
>               -member function and other acessors return the stored value as a <tt>void*</tt>.
>               +member function and other accesors return the stored value as a <tt>void*</tt>.
>                                          ^  ^
I think accessor is fine.
> to Review.  Unfortunately the issue was accidently
> to Review.  Unfortunately the issue was accidentally
>                                          ^        ^
> got <tt>swap</tt> for <tt>pair</tt> but accidently
> got <tt>swap</tt> for <tt>pair</tt> but accidentally
>                                          ^        ^
> ects.html#541">LWG 541</a> for how this accidently
> ects.html#541">LWG 541</a> for how this accidentally
>                                          ^        ^
>   issue was voted to WP in Bellevue, but accidently got stepped on by
>   issue was voted to WP in Bellevue, but accidentally got stepped on by
>                                          ^        ^
>    We do not want to be in a position of accidently introducing this
>    We do not want to be in a position of accidentally introducing this
>                                          ^        ^
> r type.  I believe this restriction was accidently removed
> r type.  I believe this restriction was accidentally removed
>                                          ^        ^
> 1.2 [func.bind.bind]/p3, p6 and p7 were accidently removed from N2798.
> 1.2 [func.bind.bind]/p3, p6 and p7 were accidentally removed from N2798.
>                                          ^        ^
>   - * resized to a value which it cannot accomodate at runtime. Illegal
>   + * resized to a value which it cannot accommodate at runtime. Illegal
>                                          ^   ^
>        -purpose without complications to accomodate other uses:
>        +purpose without complications to accommodate other uses:
>                                          ^   ^
> empting to engineer <tt>forward</tt> to accomodate uses other than perfect
> empting to engineer <tt>forward</tt> to accommodate uses other than perfect
>                                          ^   ^
>             -      type</ins> capable of accomodating 32-bit quantities.
>             +      type</ins> capable of accommodating 32-bit quantities.
>                                          ^   ^
>                     -        contributor acknowledgements and/or dedications given therein.
>                     +        contributor acknowledgments and/or dedications given therein.
>                                          ^        ^
>          -2010-11-03 Daniel comments and adjustes the currently proposed wording changes:
>          +2010-11-03 Daniel comments and adjusts the currently proposed wording changes:
>                                          ^    ^
>                      -all the other heap alogorithms.  The should be called out in the
>                      +all the other heap algorithms.  The should be called out in the
>                                          ^^
>                             -dynamically allcoated memory, passing ownership of dynamically allocated
>                             +dynamically allocated memory, passing ownership of dynamically allocated
>                                          ^   ^
>                    -Bellevue: Wording is aleady present in various standards, and no-one has come forward with wording.
>                    +Bellevue: Wording is already present in various standards, and no-one has come forward with wording.
>                                          ^ ^
>                                  -const, althought they are not member functions, and are not specified as
>                                  +const, although they are not member functions, and are not specified as
>                                          ^      ^
>                                         -ammend the constructor
>                                         +amend the constructor
>                                          ^^
>                                         -ammend the constructor
>                                         +amend the constructor
>                                          ^^
> uld.  Comments inside macros written in ancilliary
> uld.  Comments inside macros written in ancillary
>                                          ^    ^
> tside</em></span> our own macros in the ancilliary
> tside</em></span> our own macros in the ancillary
>                                          ^    ^
> lines just vanish.  Since the macros in ancilliary
> lines just vanish.  Since the macros in ancillary
>                                          ^    ^
>                                -   * the apprpriate cast to/from the custom pointer class so long as that
>                                +   * the appropriate cast to/from the custom pointer class so long as that
>                                          ^   ^
>                               -b) Add an appropiate paragraph similar to resolved 25 [lib.algorithms],
>                               +b) Add an appropriate paragraph similar to resolved 25 [lib.algorithms],
>                                          ^     ^
>               -appears to be entirely an artefact of the concepts wording.
>               +appears to be entirely an artifact of the concepts wording.
>                                          ^  ^
>      -problem. It should be used for the assignemnt operator, as with the
>      +problem. It should be used for the assignment operator, as with the
>                                          ^      ^
>                                 -Missing assignemnt operator:
>                                 +Missing assignment operator:
>                                          ^      ^
> ators is considered as QoI, because the assigments wouldn't be
> ators is considered as QoI, because the assignments wouldn't be
>                                          ^    ^
> -So as the decision was made on a wrong asumption, I propose to re-open
> +So as the decision was made on a wrong assumption, I propose to re-open
>                                          ^^
>                 -       // making future attemps less relevant. So we copy it before to
>                 +       // making future attempts less relevant. So we copy it before to
>                                          ^     ^
>                                       -  becuase a valid iterator is one that is known to be nonsingular.
>                                       +  because a valid iterator is one that is known to be nonsingular.
>                                          ^   ^
>   constructor is a more serious problem, becuase failure
>   constructor is a more serious problem, because failure
>                                          ^   ^
>            -<p>This change is reasonable becuase it clarifies the intent of this
>            +<p>This change is reasonable because it clarifies the intent of this
>                                          ^   ^
>                                -wording, becaue the new wording requires it.
>                                +wording, because the new wording requires it.
>                                          ^    ^
>         -Last but not least, the current behvaior is not only confusing to the casual
>         +Last but not least, the current behavior is not only confusing to the casual
>                                          ^   ^
> the longer names allow capabilities and behaviours
> the longer names allow capabilities and behaviors
>                                          ^     ^
>                                    -  // behaviours and guarantees of containers and algorithms defined in
>                                    +  // behaviors and guarantees of containers and algorithms defined in
>                                          ^     ^
>                                         -behaviours.
>                                         +behaviors.
>                                          ^     ^
>   is a naive algorithm.  It suffers from cancelling.
>   is a naive algorithm.  It suffers from canceling.
>                                          ^   ^
>                                         -catagories. I recommend to say instead that each container::iterator shall satisfy (and thus may refine) the forward
>                                         +categories. I recommend to say instead that each container::iterator shall satisfy (and thus may refine) the forward
>                                          ^  ^
> My opinion is that was not meant by the comitee to
> My opinion is that was not meant by the committee to
>                                          ^    ^
>                                       -A comparision of the N2461 header <tt>&lt;complex&gt;</tt> synopsis ([complex.syn])
>                                       +A comparison of the N2461 header <tt>&lt;complex&gt;</tt> synopsis ([complex.syn])
>                                          ^      ^
> cifies <tt>error_category</tt> equality comparsions based on
> cifies <tt>error_category</tt> equality comparisons based on
>                                          ^      ^
>                     -     C++11, various compability files for shared and static
>                     +     C++11, various compatibility files for shared and static
>                                          ^     ^
>                               -to ensure compatibity from both sides.
>                               +to ensure compatibility from both sides.
>                                          ^        ^
>                                   -   *  compatibilty with a C interface, this allows different
>                                   +   *  compatibility with a C interface, this allows different
>                                          ^         ^
> ode>, and <code>_Decimal128</code>, for compatibilty with the C programming language.</del>
> ode>, and <code>_Decimal128</code>, for compatibility with the C programming language.</del>
>                                          ^         ^
> sociative.reqmts] table 69, the runtime comlexity
> sociative.reqmts] table 69, the runtime complexity
>                                          ^  ^
> t>. This was intentionally fixed during conceptification,
> t>. This was intentionally fixed during conceptualization,
>                                          ^          ^
Hard core jargon ;) I think conceptification can stay.
>    -  was that library implementors were concerened about implementation
>    +  was that library implementors were concerned about implementation
>                                          ^    ^
>                                  -lock's constuction.
>                                  +lock's construction.
>                                          ^    ^
>               -<tt>explicit</tt> default contructor is defined in <tt>std::function</tt>.
>               +<tt>explicit</tt> default constructor is defined in <tt>std::function</tt>.
>                                          ^  ^
> <a name="1350"></a>1350. [FCD] Implicit contructors accidentally made some library types move-only</h3>
> <a name="1350"></a>1350. [FCD] Implicit constructors accidentally made some library types move-only</h3>
>                                          ^  ^
>                                -simply a conventient shorthand to factor common semantics into a single
>                                +simply a convenient shorthand to factor common semantics into a single
>                                          ^    ^
> Tricks</a> wiki page has information on customising the
> Tricks</a> wiki page has information on customizing the
>                                          ^      ^
> rd, rather than the 'region of storage' definiton in
> rd, rather than the 'region of storage' definition in
>                                          ^      ^
>                                 -Add new defintions to 17.3 [definitions]:
>                                 +Add new definitions to 17.3 [definitions]:
>                                          ^    ^
> le 37, in 21.2.1 [char.traits.require], descibes char_traits::assign
> le 37, in 21.2.1 [char.traits.require], describes char_traits::assign
>                                          ^   ^
>   a minimum an object is declared and is destuctible.
>   a minimum an object is declared and is destructible.
>                                          ^   ^
>                                         -diagnosable semantic rules, which means that... "a conforming
>                                         +diagnostible semantic rules, which means that... "a conforming
>                                          ^       ^
Not 100% sure, but diagnostible seems weird (the spelling checker of my 
Thunderbird agrees ;)
>                      -move clause 18.8.2 diectly to Annex D.
>                      +move clause 18.8.2 directly to Annex D.
>                                          ^ ^
> on. Is it possible to implement this as efficently as
> on. Is it possible to implement this as efficiently as
>                                          ^    ^
>                                    -     facilites, which might be undesirable in a low-memory environment or
>                                    +     facilities, which might be undesirable in a low-memory environment or
>                                          ^      ^
>                                -reserved identifers are in 17.6.3.3 [reserved.names], which are a
>                                +reserved identifiers are in 17.6.3.3 [reserved.names], which are a
>                                          ^      ^
>                                         -imaginery complex number.  With the French locale it parses as a
>                                         +imaginary complex number.  With the French locale it parses as a
>                                          ^     ^
>   -enumeration type <tt>posix_errno</tt> immediatly in the namespace <tt>std</tt>. One of
>   +enumeration type <tt>posix_errno</tt> immediately in the namespace <tt>std</tt>. One of
>                                          ^       ^
>                                         -initialisation write might be non-atomic and hence give rise to a data
>                                         +initialization write might be non-atomic and hence give rise to a data
>                                          ^       ^
>                                         -initialisation write, but that this need not happens-before all the
>                                         +initialization write, but that this need not happens-before all the
>                                          ^       ^
>                                         -initialisation. What have I overlooked here?
>                                         +initialization. What have I overlooked here?
>                                          ^       ^
>                                       -  jsut after the signature.  We need to talk to the Project Editor
>                                       +  just after the signature.  We need to talk to the Project Editor
>                                          ^ ^
>   although remain concerned about header organisation.
>   although remain concerned about header organization.
>                                          ^     ^
>      -unordered associative container is parameterized [..] by a function object Hash
>      +unordered associative container is parametrized [..] by a function object Hash
>                                          ^     ^
>                   -    with the STL type parameterized allocators, we do not need to
>                   +    with the STL type parametrized allocators, we do not need to
>                                          ^     ^
>                -   * The class %regex is parameterized around a set of related types and
>                +   * The class %regex is parametrized around a set of related types and
>                                          ^     ^
> Each unordered associative container is parameterized by <tt>Key</tt>, by a
> Each unordered associative container is parametrized by <tt>Key</tt>, by a
>                                          ^     ^
> Each unordered associative container is parameterized by <tt>Key</tt>, by a
> Each unordered associative container is parametrized by <tt>Key</tt>, by a
>                                          ^     ^
> Each unordered associative container is parameterized by <tt>Key</tt>, by a
> Each unordered associative container is parametrized by <tt>Key</tt>, by a
>                                          ^     ^
> Each unordered associative container is parameterized by <tt>Key</tt>, by a
> Each unordered associative container is parametrized by <tt>Key</tt>, by a
>                                          ^     ^
>   describing the underlying memory pool, parameterized on
>   describing the underlying memory pool, parametrized on
>                                          ^     ^
>         -2 Each associative container is parameterized on <tt>Key</tt> and an ordering
>         +2 Each associative container is parametrized on <tt>Key</tt> and an ordering
>                                          ^     ^
>           -Each associative container is parameterized on <tt>Key</tt> and an ordering
>           +Each associative container is parametrized on <tt>Key</tt> and an ordering
>                                          ^     ^
>         -2 Each associative container is parameterized on <tt>Key</tt> and an ordering
>         +2 Each associative container is parametrized on <tt>Key</tt> and an ordering
>                                          ^     ^
>                  -Each container type is parameterized on a @c Key type, a @c Hash type
>                  +Each container type is parametrized on a @c Key type, a @c Hash type
>                                          ^     ^
>                  -Each container type is parameterized on a @c Key type, and an ordering
>                  +Each container type is parametrized on a @c Key type, and an ordering
>                                          ^     ^
> p_counted_*</code> classes, this one is parameterized on the
> p_counted_*</code> classes, this one is parametrized on the
>                                          ^     ^
>                     -which is a template parameterized on the enum
>                     +which is a template parametrized on the enum
>                                          ^     ^
>            -The base of the hierarchy is parameterized on the lock policy (see below.)
>            +The base of the hierarchy is parametrized on the lock policy (see below.)
>                                          ^     ^
>                                         -parameterized on the lock policy, right up to
>                                         +parametrized on the lock policy, right up to
>                                          ^     ^
>                             -      it is parameterized on the type of the characters which it holds.
>                             +      it is parametrized on the type of the characters which it holds.
>                                          ^     ^
>                         -as an algorithm parameterized over the number of bits <tt>W</tt>. I doubt whether the given generalization
>                         +as an algorithm parametrized over the number of bits <tt>W</tt>. I doubt whether the given generalization
>                                          ^     ^
>                                    -// a parameterized type, data members are public, etc.).
>                                    +// a parametrized type, data members are public, etc.).
>                                          ^     ^
>        -need for the axiom to be further parameterized, and so the axiom can be
>        +need for the axiom to be further parametrized, and so the axiom can be
>                                          ^     ^
>              -    the allocator has been parameterized. Thus, close to optimal
>              +    the allocator has been parametrized. Thus, close to optimal
>                                          ^     ^
Jargon again, I don't think we want parametrized.

Paolo.
Jonathan Wakely July 23, 2013, 11:26 a.m. UTC | #2
I agree with all Paolo's comments.

Also libstdc++-v3/doc/html/ext/lwg-active.html is imported from
elsewhre so it's pointless fixing it, the upstream version comes from
https://github.com/cplusplus/LWG

Most of the changes are replacing British English with American
English, so low priority. I'll apply the correct parts of the patch
and commit it.

Thanks.
Ondřej Bílka July 23, 2013, 12:08 p.m. UTC | #3
On Tue, Jul 23, 2013 at 12:26:23PM +0100, Jonathan Wakely wrote:
> I agree with all Paolo's comments.
> 
> Also libstdc++-v3/doc/html/ext/lwg-active.html is imported from
> elsewhre so it's pointless fixing it, the upstream version comes from
> https://github.com/cplusplus/LWG
> 
ok, I have one redirection more.
> Most of the changes are replacing British English with American
> English, so low priority. I'll apply the correct parts of the patch
> and commit it.
> 
> Thanks.
diff mbox

Patch

diff --git a/libstdc++-v3/ChangeLog b/libstdc++-v3/ChangeLog
index 879fd61..679d1dd 100644
--- a/libstdc++-v3/ChangeLog
+++ b/libstdc++-v3/ChangeLog
@@ -1,3 +1,29 @@ 
+2013-07-23   Ondřej Bílka  <neleai@seznam.cz>
+
+	* doc/doxygen/doxygroups.cc: Fix typos in libstdc++-v3.
+	* doc/html/ext/lwg-active.html: Likewise.
+	* doc/html/ext/lwg-closed.html: Likewise.
+	* doc/html/ext/lwg-defects.html: Likewise.
+	* doc/html/manual/appendix_contributing.html: Likewise.
+	* doc/html/manual/appendix_gfdl.html: Likewise.
+	* doc/html/manual/appendix_porting.html: Likewise.
+	* doc/html/manual/bitmap_allocator.html: Likewise.
+	* doc/html/manual/configure.html: Likewise.
+	* doc/html/manual/memory.html: Likewise.
+	* doc/html/manual/policy_data_structures.html: Likewise.
+	* doc/html/manual/strings.html: Likewise.
+	* include/bits/atomic_base.h: Likewise.
+	* include/bits/regex.h: Likewise.
+	* include/bits/valarray_array.h: Likewise.
+	* include/ext/cast.h: Likewise.
+	* include/ext/concurrence.h: Likewise.
+	* include/ext/mt_allocator.h: Likewise.
+	* testsuite/ext/pb_ds/example/hash_illegal_resize.cc: Likewise.
+	* testsuite/ext/pb_ds/example/tree_intervals.cc: Likewise.
+	* testsuite/util/exception/safety.h: Likewise.
+	* testsuite/util/testsuite_hooks.cc: Likewise.
+	* testsuite/util/testsuite_hooks.h: Likewise.
+
 2013-07-22  Jason Merrill  <jason@redhat.com>
 
 	PR libstdc++/57914
diff --git a/libstdc++-v3/doc/doxygen/doxygroups.cc b/libstdc++-v3/doc/doxygen/doxygroups.cc
index d5b7aa7..bfe93eb 100644
--- a/libstdc++-v3/doc/doxygen/doxygroups.cc
+++ b/libstdc++-v3/doc/doxygen/doxygroups.cc
@@ -125,7 +125,7 @@  All sequences must meet certain requirements, summarized in
  * @ingroup containers
 Associative containers allow fast retrieval of data based on keys.
 
-Each container type is parameterized on a @c Key type, and an ordering
+Each container type is parametrized on a @c Key type, and an ordering
 relation used to sort the elements of the container.
 
 All associative containers must meet certain requirements, summarized in
@@ -136,7 +136,7 @@  All associative containers must meet certain requirements, summarized in
  * @ingroup containers
 Unordered associative containers allow fast retrieval of data based on keys.
 
-Each container type is parameterized on a @c Key type, a @c Hash type
+Each container type is parametrized on a @c Key type, a @c Hash type
 providing a hashing functor, and an ordering relation used to sort the
 elements of the container.
 
diff --git a/libstdc++-v3/doc/html/ext/lwg-active.html b/libstdc++-v3/doc/html/ext/lwg-active.html
index 3608408..ffd53d2 100644
--- a/libstdc++-v3/doc/html/ext/lwg-active.html
+++ b/libstdc++-v3/doc/html/ext/lwg-active.html
@@ -2351,7 +2351,7 @@  unordered containers do in 23.2.5 [unord.req]/3]</i>
 </p>
 
 <blockquote>
-2 Each associative container is parameterized on <tt>Key</tt> and an ordering
+2 Each associative container is parametrized on <tt>Key</tt> and an ordering
 relation <tt>Compare</tt> that induces a strict weak ordering (25.4) on elements
 of <tt>Key</tt>. In addition, <tt>map</tt> and <tt>multimap</tt> associate an
 arbitrary <ins><em>mapped type</em></ins><del>type</del> <tt>T</tt> with the
@@ -2392,7 +2392,7 @@  which is important, because both can potentially be stateful.]</i>
 
 <blockquote>
 <p>
-3 Each unordered associative container is parameterized by <tt>Key</tt>, by a
+3 Each unordered associative container is parametrized by <tt>Key</tt>, by a
 function object type <tt>Hash</tt> that meets the <tt>Hash</tt> requirements
 (20.2.4) and acts as a hash function for argument values of type <tt>Key</tt>,
 and by a binary predicate <tt>Pred</tt> that induces an equivalence relation on
@@ -2875,7 +2875,7 @@  for <tt>==</tt> and <tt>!=</tt>, but Howard convinced me not to do so (now).
 </p>
 
 <p><i>[
-2010-11-03 Daniel comments and adjustes the currently proposed wording changes:
+2010-11-03 Daniel comments and adjusts the currently proposed wording changes:
 ]</i></p>
 
 
@@ -5130,7 +5130,7 @@  comparisons into <tt>&lt;=.</tt>
 
 <p><b>Proposed resolution:</b></p>
 <p>
-Ammend [list.capacity] p1:
+Amend [list.capacity] p1:
 </p>
 <blockquote>
 <p><tt>void resize(size_type sz);</tt></p>
@@ -5922,12 +5922,12 @@  Resolution proposed in ballot comment:
 
 
 <blockquote>
-Initialisation of atomics:
+Initialization of atomics:
 <p>
 We believe the intent is that for any atomics there is a distinguished
-initialisation write, but that this need not happens-before all the
+initialization write, but that this need not happens-before all the
 other operations on that atomic - specifically so that the
-initialisation write might be non-atomic and hence give rise to a data
+initialization write might be non-atomic and hence give rise to a data
 race, and hence undefined behaviour, in examples such as this (from
 Hans):
 </p><blockquote><pre>atomic&lt;atomic&lt;int&gt; *&gt; p
@@ -7566,7 +7566,7 @@  requirement. A similar problem exists for <tt>is_placeholder</tt>.
 ]</i></p>
 
 <p>
-Alisdair recognises this is clearly a bug introduced by some wording he
+Alisdair recognizes this is clearly a bug introduced by some wording he
 wrote, the sole purpose of this metafunction is as a customization point
 for users to write their own <tt>bind</tt>-expression types that participate
 in the standard library <tt>bind</tt> protocol.  The consensus was that this
diff --git a/libstdc++-v3/doc/html/ext/lwg-closed.html b/libstdc++-v3/doc/html/ext/lwg-closed.html
index c0848eb..8b91039 100644
--- a/libstdc++-v3/doc/html/ext/lwg-closed.html
+++ b/libstdc++-v3/doc/html/ext/lwg-closed.html
@@ -8348,7 +8348,7 @@  None of these lists is meant to be exhaustive.
   that doesn't quite fit any of the named paragraph categories
   (e.g. <b>Effects</b>).  Either we need a new kind of named
   paragraph, or we need to put more material in unnamed paragraphs
-  jsut after the signature.  We need to talk to the Project Editor
+  just after the signature.  We need to talk to the Project Editor
   about how to do this.
 ]</i></p>
 
@@ -9081,7 +9081,7 @@  This issue refers to a requirements table we have removed.
 </p>
 <p>
 The issue might now relate to 24.2.7 [random.access.iterators] p5.
-However, the rationale in the issue already recognises that the
+However, the rationale in the issue already recognizes that the
 <tt>difference_type</tt> must be signed, so this really looks NAD.
 </p>
 </blockquote>
@@ -10853,7 +10853,7 @@  will hold the corresponding condition, or not."
 a) "Places" has no special meaning, and the everyday language meaning
 should fit.
 b) The corresponding conditions were negated compared to the current
-wording, becaue the new wording requires it.
+wording, because the new wording requires it.
 c) The wording "of the original range" might be redundant, since any
 subrange starting at 'first' and containing no more elements than the
 original range is implicitly a subrange of the original range [first,
@@ -11058,7 +11058,7 @@  by Thomas Mang regarding invalid iterator arithmetic expressions will
 take this into account.
 d) The wording "(for the version of unique without a predicate
 argument)" and "(for the version of unique with a predicate argument)"
-was added consciously for clarity and is in resemblence with current
+was added consciously for clarity and is in resemblance with current
 23.2.2.4 [lib.list.ops], paragraph 19. It might be considered redundant.
 e) The wording "of the original range" might be redundant, since any
 subrange starting at first and containing no more elements than the
@@ -11529,7 +11529,7 @@  clause 25.
 In that case, 25 [lib.algorithms] paragraph 9 will certainly become
 obsolete.
 Alternatively,
-b) Add an appropiate paragraph similar to resolved 25 [lib.algorithms],
+b) Add an appropriate paragraph similar to resolved 25 [lib.algorithms],
 paragraph 9, to the beginning of each clause containing invalid iterator
 arithmetic expressions.
 Alternatively,
@@ -11644,7 +11644,7 @@  not guarantee the substitution property or referential transparency).</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
 <p><b>Discussion:</b></p>
-<p>According to [lib.associative.reqmts] table 69, the runtime comlexity
+<p>According to [lib.associative.reqmts] table 69, the runtime complexity
 of insert(p, t) and erase(q) can be done in amortized constant time.</p>
 
 <p>It was my understanding that an associative container could be
@@ -12857,7 +12857,7 @@  l.remove(*l.begin());
 </p>
 <p>
 Will delete the first element, and then continue trying to access it.
-This is particularily vicious, as it will appear to work in almost all
+This is particularly vicious, as it will appear to work in almost all
 cases.
 </p>
 
@@ -16974,7 +16974,7 @@  specific documents add their rules to this issue until the list is complete.
 
 
 <p><i>[
-Bellevue: Wording is aleady present in various standards, and no-one has come forward with wording.
+Bellevue: Wording is already present in various standards, and no-one has come forward with wording.
 Suggest a formal paper rather than a defect report is the correct way to proceed.
 ]</i></p>
 
@@ -17201,7 +17201,7 @@  Consider the following example:
         // ...
 </pre>
 <p>
-Last but not least, the current behvaior is not only confusing to the casual
+Last but not least, the current behavior is not only confusing to the casual
 reader, but it has also been confusing to some book authors. Besides
 Stroustrup's book, other books (e.g. "Standard C++ IOStreams and Locales" by
 Langer and Kreft) are describing the same mistaken assumption. Although books
@@ -24878,7 +24878,7 @@  concepts.
       requirements of a random access iterator (24.1.5) such that
       <code>iterator_traits&lt;RandomAccessIterator&gt;::value_type</code>
       shall denote an <del>unsigned integral type</del><ins>unsigned integer
-      type</ins> capable of accomodating 32-bit quantities.  
+      type</ins> capable of accommodating 32-bit quantities.  
     </blockquote>
 
     <p>
@@ -25858,7 +25858,7 @@  afternoon after a busy week...
 </p>
 
 <p>
-So as the decision was made on a wrong asumption, I propose to re-open
+So as the decision was made on a wrong assumption, I propose to re-open
 the issue.
 </p>
 </blockquote>
@@ -26892,8 +26892,8 @@  Recommend NAD, addressed by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs
 <p>
 <tt>numeric_limits</tt> has functions specifically designed to return NaNs, which
 break the model of <tt>Regular</tt> (via its axioms.)  While floating point types
-will be acceptible in many algorithms taking <tt>Regular</tt> values, it is not
-appopriate for this specific API and we need a less refined constraint.
+will be acceptable in many algorithms taking <tt>Regular</tt> values, it is not
+appropriate for this specific API and we need a less refined constraint.
 </p>
 
 <p>FR 32:</p>
@@ -36179,7 +36179,7 @@  indicated:</i></p>
 
 <p>
 Object state is using a definition of object (instance of a class) from
-outside the standard, rather than the 'region of storage' definiton in
+outside the standard, rather than the 'region of storage' definition in
 1.8 [intro.object]p1
 </p>
 
@@ -38558,7 +38558,7 @@  concept_map Range&lt;const XYZCorpContainer&lt;T&gt;&gt; {
 
 <blockquote>
 <p>
-I recommend NAD, although remain concerned about header organisation.
+I recommend NAD, although remain concerned about header organization.
 </p>
 <p>
 A user container will satisfy the <tt>MemberContainer</tt> concept, which IS auto.
@@ -40905,7 +40905,7 @@  In X [rand.concept.urng], we have the following:
 
 <p>
 Since the parameter <tt>G</tt> is in scope throughout the concept, there is no
-need for the axiom to be further parameterized, and so the axiom can be
+need for the axiom to be further parametrized, and so the axiom can be
 slightly simplified as:
 </p>
 
@@ -45265,7 +45265,7 @@  you sort it out.
 Most reserved identifiers are treated as unilaterally available to the
 implementation, such as to implement language extensions, or provide
 macros documenting its functionality. However, the requirements for
-reserved identifers are in 17.6.3.3 [reserved.names], which are a
+reserved identifiers are in 17.6.3.3 [reserved.names], which are a
 subsection of 17.6.3 [constraints]. 17.6.3.1 [constraints.overview] appears only to apply to "C++ programs
 that use the facilities of the C++ standard library", meaning that, in
 theory, all implementations are erroneous in having any non-standard
@@ -45333,7 +45333,7 @@  updated paper, and hopefully tracked via the LWG issues list instead.
 It seems there are several classes of problems here and finding wording
 to solve all in one paragraph could be too much.  I suspect we need
 several overlapping requirements that should cover the desired range of
-behaviours.
+behaviors.
 </p>
 
 <p>
@@ -46733,7 +46733,7 @@  to the FCD
 
 <p>
 This issue was discussed in Pittsburgh, and the decision there was to accept the
-typedef as proposed and move to Review.  Unfortunately the issue was accidently
+typedef as proposed and move to Review.  Unfortunately the issue was accidentally
 applied to the FCD, and incorrectly.  The FCD version of the typedef refers to
 <tt>ratio&lt;N, D&gt;</tt>, but the typedef is intended to refer to
 <tt>ratio&lt;num, den&gt;</tt> which in general is not the same type.
@@ -49064,7 +49064,7 @@  core feature Move Special Member Functions (N3044).
 
 
 <hr>
-<h3><a name="1350"></a>1350. [FCD] Implicit contructors accidentally made some library types move-only</h3>
+<h3><a name="1350"></a>1350. [FCD] Implicit constructors accidentally made some library types move-only</h3>
 <p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
  <b>Submitter:</b> Switzerland <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-10-25</p>
 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#library">active issues</a> in [library].</p>
@@ -50206,7 +50206,7 @@  Depends on result of the review of WG14 work,
 which is expected to be out to ballot during the
 time wg21 is resolving its own ballot comments.
 Liaison may also want to file comments in WG14
-to ensure compatibity from both sides.
+to ensure compatibility from both sides.
 </p>
 
 
diff --git a/libstdc++-v3/doc/html/ext/lwg-defects.html b/libstdc++-v3/doc/html/ext/lwg-defects.html
index c1a3c78..06e1e72 100644
--- a/libstdc++-v3/doc/html/ext/lwg-defects.html
+++ b/libstdc++-v3/doc/html/ext/lwg-defects.html
@@ -10869,7 +10869,7 @@  suggests so the LWG can decide between the two options.]</i></p>
   defect fixing.  We're now more sympathetic to it, but we (especially
   Bill) are still worried about performance.  N1780 describes a naive
   algorithm, but it's not clear whether there is a non-naive
-  implementation. Is it possible to implement this as efficently as
+  implementation. Is it possible to implement this as efficiently as
   the current version of insert?]</i></p>
 
 
@@ -11969,7 +11969,7 @@  something like <tt>throw std::out_of_range("foo")</tt>, the const
 string&amp; constructor is invoked before anything gets thrown.  The
 copy constructor is potentially invoked during stack unwinding.</p>
 
-<p>The copy constructor is a more serious problem, becuase failure
+<p>The copy constructor is a more serious problem, because failure
 during stack unwinding invokes <tt>terminate</tt>.  The copy
 constructor must be nothrow. <i>Curaçao: Howard thinks this
 requirement may already be present.</i></p>
@@ -13536,7 +13536,7 @@  the wording.  Dave provided new wording.]</i></p>
   "singular".</p>
 
 <p>Why do we say "may be singular", instead of "is singular"?  That's
-  becuase a valid iterator is one that is known to be nonsingular.
+  because a valid iterator is one that is known to be nonsingular.
   Invalidating an iterator means changing it in such a way that it's
   no longer known to be nonsingular.  An example: inserting an
   element into the middle of a vector is correctly said to invalidate
@@ -16261,7 +16261,7 @@  code example. That code example is however quite
 inefficient because it requires several useless copies
 of both the passed key_type value and of default
 constructed mapped_type instances.
-My opinion is that was not meant by the comitee to
+My opinion is that was not meant by the committee to
 require all those temporary copies. 
 </p>
 
@@ -16378,7 +16378,7 @@  we are no longer defining <tt>operator[]</tt> in terms of
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-Table 37, in 21.2.1 [char.traits.require], descibes char_traits::assign
+Table 37, in 21.2.1 [char.traits.require], describes char_traits::assign
 as:
 </p>
 <pre>  X::assign(c,d)   assigns c = d.
@@ -16930,7 +16930,7 @@  shown in Table 51:
 
 <p>The LWG considered, and rejected, an alternate proposal (described
   as "Option 2" in the discussion).  The main reason for rejecting it
-  was that library implementors were concerened about implementation
+  was that library implementors were concerned about implementation
   difficult, given that getting a C++ library to work smoothly with a
   separately written C library is already a delicate business.  Some
   library implementers were also concerned about the issue of adding
@@ -17451,7 +17451,7 @@  prevents locale from being implemented efficiently.
 
 
 <p><b>Rationale:</b></p>
-<p>This change is reasonable becuase it clarifies the intent of this
+<p>This change is reasonable because it clarifies the intent of this
   part of the standard.</p>
 
 
@@ -17837,7 +17837,7 @@  function.
 
 <p>
 Although clause 23.1.2/8 guarantees that i remains a valid iterator
-througout this loop, absence of the stability requirement could
+throughout this loop, absence of the stability requirement could
 potentially result in elements being skipped. This would make
 this code incorrect, and, furthermore, means that there is no way
 of erasing these elements without iterating first over the entire
@@ -18603,7 +18603,7 @@  impact on allowable optimizations.</p>
 <p><b>Discussion:</b></p>
 <p>
 The specifications of toupper and tolower both specify the functions as
-const, althought they are not member functions, and are not specified as
+const, although they are not member functions, and are not specified as
 const in the header file synopsis in section 22.3 [locales].
 </p>
 
@@ -23500,7 +23500,7 @@  list&lt;double&gt; &gt; should not take O(1).</p>
 
 
 <p><i>[
-Post Oxford:  We got <tt>swap</tt> for <tt>pair</tt> but accidently
+Post Oxford:  We got <tt>swap</tt> for <tt>pair</tt> but accidentally
 missed <tt>tuple</tt>.  <tt>tuple::swap</tt> is being tracked by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#522">522</a>.
 ]</i></p>
 
@@ -28421,7 +28421,7 @@  In Berlin, WG14 decided to drop the &lt;decfloat.h&gt; header.  The contents of
 <del>The standard C++ headers <code>&lt;cfloat&gt;</code> and <code>&lt;float.h&gt;</code> define characteristics of the floating-point types <code>float</code>, <code>double</code>, and <code>long double</code>.  Their contents remain unchanged by this Technical Report.</del>
 </p>
 <p>
-<del>Headers <code>&lt;cdecfloat&gt;</code> and <code>&lt;decfloat.h&gt;</code> define characteristics of the decimal floating-point types <code>decimal32</code>, <code>decimal64</code>, and <code>decimal128</code>.  As well, <code>&lt;decfloat.h&gt;</code> defines the convenience typedefs <code>_Decimal32</code>, <code>_Decimal64</code>, and <code>_Decimal128</code>, for compatibilty with the C programming language.</del>
+<del>Headers <code>&lt;cdecfloat&gt;</code> and <code>&lt;decfloat.h&gt;</code> define characteristics of the decimal floating-point types <code>decimal32</code>, <code>decimal64</code>, and <code>decimal128</code>.  As well, <code>&lt;decfloat.h&gt;</code> defines the convenience typedefs <code>_Decimal32</code>, <code>_Decimal64</code>, and <code>_Decimal128</code>, for compatibility with the C programming language.</del>
 </p>
 <p>
 <ins>The header <code>&lt;cfloat&gt;</code> is described in [tr.c99.cfloat].  The header <code>&lt;float.h&gt;</code> is described in [tr.c99.floath]. These headers are extended by this Technical Report to define characteristics of the decimal floating-point types <code>decimal32</code>, <code>decimal64</code>, and <code>decimal128</code>.  As well, <code>&lt;float.h&gt;</code> is extended to define the convenience typedefs <code>_Decimal32</code>, <code>_Decimal64</code>, and <code>_Decimal128</code> for compatibility with the C programming language.</ins>
@@ -29719,7 +29719,7 @@  Change 28.8.2 [re.regex.construct]:
 <p>
 is there an issue opened for (0,3) as complex number with
 the French local?  With the English local, the above parses as an
-imaginery complex number.  With the French locale it parses as a
+imaginary complex number.  With the French locale it parses as a
 real complex number.
 </p>
 
@@ -31619,7 +31619,7 @@  for all of these changes.
 Even though <tt>unique_ptr&lt;void&gt;</tt> is not a valid use case (unlike for <tt>shared_ptr&lt;void&gt;</tt>),
 unexpected cases to crop up which require the instantiation of the interface of <tt>unique_ptr&lt;void&gt;</tt>
 even if it is never used.  For example see
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#541">LWG 541</a> for how this accidently
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#541">LWG 541</a> for how this accidentally
 happened to <tt>auto_ptr</tt>.  I believe the most robust way to protect <tt>unique_ptr</tt> against this
 type of failure is to augment the return type of <tt>unique_ptr&lt;T&gt;:operator*()</tt> with
 <tt>add_lvalue_reference&lt;T&gt;::type</tt>.  This means that given an instantiated <tt>unique_ptr&lt;void&gt;</tt>
@@ -32127,7 +32127,7 @@  post Bellevue Howard adds:
 
 <blockquote>
 <p>
-This issue was voted to WP in Bellevue, but accidently got stepped on by
+This issue was voted to WP in Bellevue, but accidentally got stepped on by
 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2525.pdf">N2525</a>
 which was voted to WP simulataneously.  Moving back to Open for the purpose of getting
 the wording right.  The intent of this issue and N2525 are not in conflict.
@@ -34055,7 +34055,7 @@  as well as the current draft
 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2284.pdf">N2284</a>
 (section 19.5 [syserr], p.2) proposes a
 new
-enumeration type <tt>posix_errno</tt> immediatly in the namespace <tt>std</tt>. One of
+enumeration type <tt>posix_errno</tt> immediately in the namespace <tt>std</tt>. One of
 the enumerators has the name <tt>invalid_argument</tt>, or fully qualified:
 <tt>std::invalid_argument</tt>. This name clashes with the exception type
 <tt>std::invalid_argument</tt>, see 19.2 [std.exceptions]/p.3. This clash makes
@@ -36459,7 +36459,7 @@  I wonder how the constructor <tt>bitset&lt;N&gt;::bitset(unsigned long)</tt> can
 be declared as a <tt>constexpr</tt>. Current implementations usually have no such <tt>bitset</tt>
 c'tor which would fulfill the requirements of a <tt>constexpr</tt> c'tor because they have a
 non-empty c'tor body that typically contains for-loops or <tt>memcpy</tt> to compute the
-initialisation. What have I overlooked here?
+initialization. What have I overlooked here?
 </li>
 </ol>
 
@@ -36733,7 +36733,7 @@  column is valid, but not clear what semantics we need.
 A table where there is no post-condition seems odd, but appears to sum up our position best.
 </p>
 <p>
-At a minimum an object is declared and is destuctible.
+At a minimum an object is declared and is destructible.
 </p>
 <p>
 Move to open, as no-one happy to produce wording on the fly.
@@ -37397,7 +37397,7 @@  e, fmt, flags)</tt>, and then returns <tt>result</tt>.
 <p><b>Discussion:</b></p>
 <p>
 The <tt>mersenne_twister_engine</tt> is required to use a seeding method that is given 
-as an algorithm parameterized over the number of bits <tt>W</tt>. I doubt whether the given generalization 
+as an algorithm parametrized over the number of bits <tt>W</tt>. I doubt whether the given generalization 
 of an algorithm that was originally developed only for unsigned 32-bit integers is appropriate 
 for other bit widths. For instance, <tt>W</tt> could be theoretically 16 and <tt>UIntType</tt> a 16-bit integer, in 
 which case the given multiplier would not fit into the <tt>UIntType</tt>. Moreover, T. Nishimura and M. 
@@ -38351,7 +38351,7 @@  possibly more concise too.
 
 <p><b>Proposed resolution:</b></p>
 <p>
-Add new defintions to 17.3 [definitions]:
+Add new definitions to 17.3 [definitions]:
 </p>
 
 <blockquote>
@@ -38912,7 +38912,7 @@  The <tt>unique_ptr</tt> provides a semantics of strict ownership. A
 <tt>MoveAssignable</tt>. <ins>The template parameter <tt>T</tt> of
 <tt>unique_ptr</tt> may be an incomplete type.</ins> [ <i>Note:</i> The
 uses of <tt>unique_ptr</tt> include providing exception safety for
-dynamically allcoated memory, passing ownership of dynamically allocated
+dynamically allocated memory, passing ownership of dynamically allocated
 memory to a function, and returning dynamically allocated memory from a
 function. -- <i>end note</i> ]
 </blockquote>
@@ -41464,7 +41464,7 @@  requirements (Table 33), and the the <tt>MoveAssignable</tt> requirements (Table
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-A comparision of the N2461 header <tt>&lt;complex&gt;</tt> synopsis ([complex.syn])
+A comparison of the N2461 header <tt>&lt;complex&gt;</tt> synopsis ([complex.syn])
 with the C99 standard (ISO 9899, 2nd edition and the two corrigenda) show
 some complex functions that are missing in C++. These are:
 </p>
@@ -44302,7 +44302,7 @@  a place to see the complete solution in one place.
 <tt>bind</tt> needs to be "moved".
 </li>
 <li>
-20.8.10.1.2 [func.bind.bind]/p3, p6 and p7 were accidently removed from N2798.
+20.8.10.1.2 [func.bind.bind]/p3, p6 and p7 were accidentally removed from N2798.
 </li>
 <li>
 Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#929">929</a> argues for a way to pass by &amp;&amp; for
@@ -49908,7 +49908,7 @@  comparators, as described in 23.2.4 [associative.reqmts]/2:
 </p>
 
 <blockquote>
-Each associative container is parameterized on <tt>Key</tt> and an ordering
+Each associative container is parametrized on <tt>Key</tt> and an ordering
 relation <tt>Compare</tt> that
 induces a strict weak ordering (25.3) on elements of Key. [..]. The
 object of type <tt>Compare</tt> is
@@ -49927,7 +49927,7 @@  equality predicate, see
 
 <blockquote>
 <p>
-Each unordered associative container is parameterized by <tt>Key</tt>, by a
+Each unordered associative container is parametrized by <tt>Key</tt>, by a
 function object <tt>Hash</tt> that
 acts as a hash function for values of type <tt>Key</tt>, and by a binary
 predicate <tt>Pred</tt> that induces an
@@ -50063,7 +50063,7 @@  conversion function to e.g. pointer to function from being used in algorithms.
 Now this last term "function objects" itself brings us to a third unsatisfactory
 state: The term is used both for objects (e.g. "Function objects are
 objects[..]" in 20.8 [function.objects]/1) and for types (e.g. "Each
-unordered associative container is parameterized [..] by a function object Hash
+unordered associative container is parametrized [..] by a function object Hash
 that acts as a hash function [..]" in 23.2.5 [unord.req]/3). This
 impreciseness should be fixed and I suggest to introduce the term <em>function
 object type</em> as the counter part to <em>callable type</em>. This word seems
@@ -50289,7 +50289,7 @@  because the explicit naming of "pointer to function" is misleading]</i>
 </p>
 
 <blockquote>
-2 Each associative container is parameterized on <tt>Key</tt> and an ordering
+2 Each associative container is parametrized on <tt>Key</tt> and an ordering
 relation <tt>Compare</tt> that induces a strict weak ordering (25.4 [alg.sorting]) on elements of <tt>Key</tt>. In addition, <tt>map</tt>
 and <tt>multimap</tt> associate an arbitrary type <tt>T</tt> with the
 <tt>Key</tt>. The object of type <tt>Compare</tt> is called the comparison
@@ -50304,7 +50304,7 @@  Change 23.2.5 [unord.req]/3 as indicated:
 </p>
 
 <blockquote>
-3 Each unordered associative container is parameterized by <tt>Key</tt>, by a
+3 Each unordered associative container is parametrized by <tt>Key</tt>, by a
 function object <ins>type</ins> <tt>Hash</tt> that acts as a hash function for
 values of type <tt>Key</tt>, and by a binary predicate <tt>Pred</tt> that
 induces an equivalence relation on values of type Key. [..]
@@ -51214,7 +51214,7 @@  Recommend <del>NAD Editorial</del><ins>Resolved</ins>, fixed by
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
 <p><b>Discussion:</b></p>
 <blockquote><pre>20.2.3 pairs
-Missing assignemnt operator:
+Missing assignment operator:
 template&lt;class U , class V&gt;
   requires CopyAssignable&lt;T1, U&gt; &amp;&amp; CopyAssignable&lt;T2, V&gt;
     pair&amp; operator=(pair&lt;U , V&gt; const &amp; p );
@@ -54305,7 +54305,7 @@  Wording supplied by Daniel.
 
 <p>
 20.9.9.2.1 [unique.ptr.single.ctor]/5 no longer requires for <tt>D</tt>
-not to be a pointer type.  I believe this restriction was accidently removed
+not to be a pointer type.  I believe this restriction was accidentally removed
 when we relaxed the completeness reuqirements on <tt>T</tt>. The restriction
 needs to be put back in.  Otherwise we have a run time failure that could
 have been caught at compile time:
@@ -59438,7 +59438,7 @@  struct integral_constant {
 
 <p>
 The <tt>nullptr_t</tt> type was introduced to resolve the null pointer literal
-problem. It should be used for the assignemnt operator, as with the
+problem. It should be used for the assignment operator, as with the
 constructor and elsewhere through the library.
 </p>
 
@@ -59717,7 +59717,7 @@  represented by <tt>*this</tt> has completed.</ins> <tt>get_id() == id()</tt>.
 <p>
 It is not clear what purpose the Requirement tables serve in the
 Containers clause. Are they the definition of a library Container? Or
-simply a conventient shorthand to factor common semantics into a single
+simply a convenient shorthand to factor common semantics into a single
 place, simplifying the description of each subsequent container? This
 becomes an issue for 'containers' like <tt>array</tt>, which does not meet the
 default-construct-to-empty requirement, or <tt>forward_list</tt> which does not
@@ -60523,7 +60523,7 @@  void f(T&amp;&amp; x)
 </pre></blockquote>
 
 <p>
-Attempting to engineer <tt>forward</tt> to accomodate uses other than perfect
+Attempting to engineer <tt>forward</tt> to accommodate uses other than perfect
 forwarding dilutes its idiomatic meaning.  The solution proposed here
 declares that <tt>forward&lt;T&gt;(x)</tt> means nothing more than <tt>static_cast&lt;T&amp;&amp;&gt;(x)</tt>,
 with a patchwork of restrictions on what <tt>T</tt> and <tt>x</tt> can be that can't be
@@ -60539,7 +60539,7 @@  can't guarantee) I got right.
 <li>
 <p>
 Use a simple definition of <tt>forward</tt> that accomplishes its original
-purpose without complications to accomodate other uses:
+purpose without complications to accommodate other uses:
 </p>
 
 <blockquote><pre>template &lt;class T, class U&gt;
@@ -61481,7 +61481,7 @@  Moved to Ready.
 <blockquote>
 <p>
 Looking again at LWG #1079, the wording in the issue no longer exists, and
-appears to be entirely an artefact of the concepts wording.
+appears to be entirely an artifact of the concepts wording.
 </p>
 
 <p>
@@ -63388,7 +63388,7 @@  clear of that class while other constructor-related issues settle.
 
 <p><b>Proposed resolution:</b></p>
 <p>
-Ammend the tuple class template declaration in 20.4.2 [tuple.tuple] as
+Amend the tuple class template declaration in 20.4.2 [tuple.tuple] as
 follows
 </p>
 
@@ -63403,7 +63403,7 @@  Add the following concept:
 </pre></blockquote>
 
 <p>
-ammend the constructor 
+amend the constructor 
 </p>
 
 <blockquote><pre><ins>template &lt;class... UTypes&gt;
@@ -63418,7 +63418,7 @@  template &lt;class... UTypes&gt;
 </pre></blockquote>
 
 <p>
-ammend the constructor
+amend the constructor
 </p>
 
 <blockquote><pre><ins>template &lt;class... UTypes&gt;
@@ -63904,7 +63904,7 @@  Set to Tentatively Ready after 5 positive votes on c++std-lib.
 
 <p><b>Proposed resolution:</b></p>
 <p>
-Ammend in both:<br>
+Amend in both:<br>
 24.6.3 [istreambuf.iterator]<br>
 24.6.3.5 [istreambuf.iterator::equal]<br>
 </p>
@@ -65407,7 +65407,7 @@  required to use a monotonic clock because such a clock may be unavailable.
 <p><b>UK 327 Suggestion</b></p>
         <p>Add a precondition <tt>!owns</tt>. Change the 'i.e.'
         in the error condition to be 'e.g.' to allow for this
-        condition to propogate deadlock detection by the host OS.</p>
+        condition to propagate deadlock detection by the host OS.</p>
 <p><b>UK 327 Notes</b></p>
 <p>Create an issue. Assigned to Lawrence Crowl. Note: not sure what try_lock 
     means for recursive locks when you are the owner. POSIX has language on 
@@ -67853,7 +67853,7 @@  from, for example an <tt>int</tt>.  Is this intended to compile?
 <p>
 Before the addition of this constructor, <tt>queue&lt;int&gt;(5)</tt> would not compile.
 I ask, not because this crashes, but because it is new and appears to be
-unintended.  We do not want to be in a position of accidently introducing this
+unintended.  We do not want to be in a position of accidentally introducing this
 "feature" in C++0X and later attempting to remove it.
 </p>
 
@@ -68375,7 +68375,7 @@  Move to NAD.
 It's not clear that there's any important difference between
 "ill-formed" and "diagnostic required". From 1.4 [intro.compliance], 1.3.9 [defns.ill.formed], and 1.3.26 [defns.well.formed] it appears that an ill-formed program is one
 that is not correctly constructed according to the syntax rules and
-diagnosable semantic rules, which means that... "a conforming
+diagnostible semantic rules, which means that... "a conforming
 implementation shall issue at least one diagnostic message." The
 author's intent seems to be that we should be requiring a fatal error
 instead of a mere warning, but the standard just doesn't have language
@@ -69668,7 +69668,7 @@  Add to p1 25.4.5.1 [includes]:
 
 <p>
 The effects clause is invalid if the range <tt>[first,last)</tt> is empty, unlike
-all the other heap alogorithms.  The should be called out in the
+all the other heap algorithms.  The should be called out in the
 requirements.
 </p>
 
@@ -71408,7 +71408,7 @@  A lot of fixes were silently applied during concept-time and we should
 not lose them again. The Requires clause of 25.3.9 [alg.unique]/5
 doesn't mention that <tt>==</tt> and the predicate need to satisfy an
 <tt>EquivalenceRelation</tt>, as it is correctly said for
-<tt>unique</tt>. This was intentionally fixed during conceptification,
+<tt>unique</tt>. This was intentionally fixed during conceptualization,
 were we had:
 </p>
 
@@ -71687,7 +71687,7 @@  the argument <tt>k</tt>. [<i>Note:</i> Thus all evaluations of the expression <t
 
   <p><i>Change Unordered associative containers 23.2.5 [unord.req] as indicated:</i></p>
 <blockquote>
-  <p>Each unordered associative container is parameterized by <tt>Key</tt>, by a 
+  <p>Each unordered associative container is parametrized by <tt>Key</tt>, by a 
   function object <ins>type</ins> <tt>Hash</tt><ins>([hash.requirements])</ins> that acts as a hash 
   function for <ins>argument</ins> values of type <tt>Key</tt>, 
   and by a binary predicate <tt>Pred</tt> that induces an equivalence relation 
@@ -71775,7 +71775,7 @@  Add the term "exposition only" in the following two places:
 </p>
 
 <p>
-Ammend D.12.1 [auto.ptr]p2:
+Amend D.12.1 [auto.ptr]p2:
 </p>
 
 <blockquote>
@@ -72891,7 +72891,7 @@  supported.
 
 <p><b>Proposed resolution:</b></p>
 <p>
-Ammend p3 Freestanding implementations 17.6.1.3 [compliance]
+Amend p3 Freestanding implementations 17.6.1.3 [compliance]
 </p>
 
 <blockquote>
@@ -73277,7 +73277,7 @@  normal and exceptional circumstances. 
 <blockquote>
 2 Some lock constructors take tag types which describe what should be
 done with the <del>mutex</del><ins>lockable</ins> object during the
-lock's constuction.
+lock's construction.
 </blockquote>
 
 <p>30.4.2.1 [thread.lock.guard] paragaph 1:</p>
@@ -75949,7 +75949,7 @@  Post-Rapperswil:
 
 <p>
 Daniel notes: I changed the currently suggested P/R slightly, because it is not robust in regard to new fundamental iterator
-catagories. I recommend to say instead that each container::iterator shall satisfy (and thus may refine) the forward 
+categories. I recommend to say instead that each container::iterator shall satisfy (and thus may refine) the forward 
 iterator requirements.
 </p>
 
@@ -76778,7 +76778,7 @@  the initialization marked with # could be well-formed.
 
 <p><i>[
 Only constraints on constructors are suggested. Adding similar constraints on
-assignment operators is considered as QoI, because the assigments wouldn't be
+assignment operators is considered as QoI, because the assignments wouldn't be
 well-formed anyway.
 ]</i></p>
 
@@ -79292,7 +79292,7 @@  Resolved in Rapperswil by a motion to directly apply the words from the ballot c
 
 <p><b>Proposed resolution:</b></p>
 With the exception of 18.8.2.1 [bad.exception],
-move clause 18.8.2 diectly to Annex D.
+move clause 18.8.2 directly to Annex D.
 [bad.exception] should simply become the new
 18.8.2.
 
@@ -79429,7 +79429,7 @@  Adopted at 2010-11 Batavia
 <p>
 The C++0x FCD recommends, in a note (see 19.5.1.1/1), that users
 create a single <tt>error_category</tt> object for each user defined error
-category and specifies <tt>error_category</tt> equality comparsions based on
+category and specifies <tt>error_category</tt> equality comparisons based on
 equality of addresses (19.5.1.3). The Draft apparently ignores this
 when specifying standard error category objects in section 19.5.1.5,
 by allowing the <tt>generic_category()</tt> and <tt>system_category()</tt>
@@ -80111,7 +80111,7 @@  Resolved by paper <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/20
 Several type traits require compiler support, e.g.
 <tt>std::is_constructible</tt> or <tt>std::is_convertible</tt>.
 Their current specification seems to imply, that the corresponding
-test expressions should be well-formed, even in absense of access:
+test expressions should be well-formed, even in absence of access:
 </p>
 <pre>class X { X(int){} };
 constexpr bool test = std::is_constructible&lt;X, int&gt;::value;
@@ -80335,7 +80335,7 @@  Resolved by paper <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/20
 <p><b>Discussion:</b></p>
 <p><b>Addresses JP-3</b></p>
 <p>
-<tt>explicit</tt> default contructor is defined in <tt>std::function</tt>.
+<tt>explicit</tt> default constructor is defined in <tt>std::function</tt>.
 Although it is allowed according to 12.3.1, it seems
 unnecessary to qualify the constructor as <tt>explicit</tt>.
 If it is <tt>explicit</tt>, there will be a limitation in <tt>initializer_list</tt>.
@@ -82302,7 +82302,7 @@  Resolved in Batavia by accepting
 
 The <tt>compare_exchange_weak</tt> and <tt>compare_exchange_strong</tt> member functions that take
 <tt>const void*</tt> arguments lead to a silent removal of <tt>const</tt>, because the <tt>load</tt> 
-member function and other acessors return the stored value as a <tt>void*</tt>.
+member function and other accesors return the stored value as a <tt>void*</tt>.
 
 <p><i>[
 Proposed resolution as of NB comment:
diff --git a/libstdc++-v3/doc/html/manual/appendix_contributing.html b/libstdc++-v3/doc/html/manual/appendix_contributing.html
index fb30f36..00e7750 100644
--- a/libstdc++-v3/doc/html/manual/appendix_contributing.html
+++ b/libstdc++-v3/doc/html/manual/appendix_contributing.html
@@ -94,7 +94,7 @@ 
 	  version of diff does not support these options, then get the
 	  latest version of GNU
 	  diff. The <a class="link" href="http://gcc.gnu.org/wiki/SvnTricks" target="_top">SVN
-	  Tricks</a> wiki page has information on customising the
+	  Tricks</a> wiki page has information on customizing the
 	  output of <code class="code">svn diff</code>.
 	</p></li><li class="listitem"><p>
 	  When you have all these pieces, bundle them up in a
diff --git a/libstdc++-v3/doc/html/manual/appendix_gfdl.html b/libstdc++-v3/doc/html/manual/appendix_gfdl.html
index d0531b6..d718c90 100644
--- a/libstdc++-v3/doc/html/manual/appendix_gfdl.html
+++ b/libstdc++-v3/doc/html/manual/appendix_gfdl.html
@@ -227,7 +227,7 @@ 
         For any section Entitled “Acknowledgements” or
         “Dedications”, Preserve the Title of the section, and
         preserve in the section all the substance and tone of each of the
-        contributor acknowledgements and/or dedications given therein.
+        contributor acknowledgments and/or dedications given therein.
       </li><li class="listitem">
         Preserve all the Invariant Sections of the Document, unaltered in
         their text and in their titles. Section numbers or the equivalent are
diff --git a/libstdc++-v3/doc/html/manual/appendix_porting.html b/libstdc++-v3/doc/html/manual/appendix_porting.html
index 44f6bfd..47c4fec 100644
--- a/libstdc++-v3/doc/html/manual/appendix_porting.html
+++ b/libstdc++-v3/doc/html/manual/appendix_porting.html
@@ -90,13 +90,13 @@  in the build directory starts the build process. The <code class="literal">all</
 </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a id="build_hacking.configure.conventions"></a>Coding and Commenting Conventions</h4></div></div></div><p>
     Most comments should use {octothorpes, shibboleths, hash marks,
     pound signs, whatever} rather than "dnl".  Nearly all comments in
-    configure.ac should.  Comments inside macros written in ancilliary
+    configure.ac should.  Comments inside macros written in ancillary
     .m4 files should.  About the only comments which should
     <span class="emphasis"><em>not</em></span> use #, but use dnl instead, are comments
-    <span class="emphasis"><em>outside</em></span> our own macros in the ancilliary
+    <span class="emphasis"><em>outside</em></span> our own macros in the ancillary
     files.  The difference is that # comments show up in
     <code class="code">configure</code> (which is most helpful for debugging),
-    while dnl'd lines just vanish.  Since the macros in ancilliary
+    while dnl'd lines just vanish.  Since the macros in ancillary
     files generate code which appears in odd places, their "outside"
     comments tend to not be useful while reading
     <code class="code">configure</code>.
@@ -280,7 +280,7 @@  in the build directory starts the build process. The <code class="literal">all</
      make src
    </p><p>
      Generates two convenience libraries, one for C++98 and one for
-     C++11, various compability files for shared and static
+     C++11, various compatibility files for shared and static
      libraries, and then collects all the generated bits and creates
      the final libstdc++ libraries.
   </p><div class="orderedlist"><ol class="orderedlist" type="a"><li class="listitem"><p>
diff --git a/libstdc++-v3/doc/html/manual/bitmap_allocator.html b/libstdc++-v3/doc/html/manual/bitmap_allocator.html
index fc48f65..56d1603 100644
--- a/libstdc++-v3/doc/html/manual/bitmap_allocator.html
+++ b/libstdc++-v3/doc/html/manual/bitmap_allocator.html
@@ -13,10 +13,10 @@ 
     while 0 indicates allocated. This has been done so that you can
     easily check a collection of bits for a free block. This kind of
     Bitmapped strategy works best for single object allocations, and
-    with the STL type parameterized allocators, we do not need to
+    with the STL type parametrized allocators, we do not need to
     choose any size for the block which will be represented by a
     single bit. This will be the size of the parameter around which
-    the allocator has been parameterized. Thus, close to optimal
+    the allocator has been parametrized. Thus, close to optimal
     performance will result. Hence, this should be used for node based
     containers which call the allocate function with an argument of 1.
   </p><p>
diff --git a/libstdc++-v3/doc/html/manual/configure.html b/libstdc++-v3/doc/html/manual/configure.html
index 5526dee..2cb6459 100644
--- a/libstdc++-v3/doc/html/manual/configure.html
+++ b/libstdc++-v3/doc/html/manual/configure.html
@@ -224,7 +224,7 @@ 
      to standard error for certain events such as calling a pure virtual
      function or the invocation of the standard terminate handler.  Those
      messages cause the library to depend on the demangler and standard I/O
-     facilites, which might be undesirable in a low-memory environment or
+     facilities, which might be undesirable in a low-memory environment or
      when standard error is not available.  This option disables those
      messages.  This option does not change the library ABI.
    </p></dd></dl></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="setup.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="setup.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="make.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 2. Setup </td><td width="20%" align="center"><a accesskey="h" href="../index.html">Home</a></td><td width="40%" align="right" valign="top"> Make</td></tr></table></div></body></html>
\ No newline at end of file
diff --git a/libstdc++-v3/doc/html/manual/memory.html b/libstdc++-v3/doc/html/manual/memory.html
index 7d678da..8133adf 100644
--- a/libstdc++-v3/doc/html/manual/memory.html
+++ b/libstdc++-v3/doc/html/manual/memory.html
@@ -453,7 +453,7 @@  pointer of type <span class="type">_Sp_counted_base*</span> which points to the
 object that maintains the reference-counts and destroys the managed
 resource.
     </p><div class="variablelist"><dl class="variablelist"><dt><span class="term"><code class="classname">_Sp_counted_base&lt;Lp&gt;</code></span></dt><dd><p>
-The base of the hierarchy is parameterized on the lock policy (see below.)
+The base of the hierarchy is parametrized on the lock policy (see below.)
 _Sp_counted_base doesn't depend on the type of pointer being managed,
 it only maintains the reference counts and calls virtual functions when
 the counts drop to zero. The managed object is destroyed when the last
@@ -484,7 +484,7 @@  Contains aligned storage to hold an object of type <span class="type">Tp</span>,
 which is constructed in-place with placement <code class="function">new</code>.
 Has a variadic template constructor allowing any number of arguments to
 be forwarded to <span class="type">Tp</span>'s constructor.
-Unlike the other <code class="classname">_Sp_counted_*</code> classes, this one is parameterized on the
+Unlike the other <code class="classname">_Sp_counted_*</code> classes, this one is parametrized on the
 type of object, not the type of pointer; this is purely a convenience
 that simplifies the implementation slightly.
     </p></dd></dl></div><p>
@@ -540,9 +540,9 @@  Policy below for details.
 </p></div><div class="section"><div class="titlepage"><div><div><h5 class="title"><a id="idm140623071342672"></a>Selecting Lock Policy</h5></div></div></div><p>
     </p><p>
 There is a single <code class="classname">_Sp_counted_base</code> class,
-which is a template parameterized on the enum
+which is a template parametrized on the enum
 <span class="type">__gnu_cxx::_Lock_policy</span>.  The entire family of classes is
-parameterized on the lock policy, right up to
+parametrized on the lock policy, right up to
 <code class="classname">__shared_ptr</code>, <code class="classname">__weak_ptr</code> and
 <code class="classname">__enable_shared_from_this</code>. The actual
 <code class="classname">std::shared_ptr</code> class inherits from
diff --git a/libstdc++-v3/doc/html/manual/policy_data_structures.html b/libstdc++-v3/doc/html/manual/policy_data_structures.html
index 6b5ee4b..8325406 100644
--- a/libstdc++-v3/doc/html/manual/policy_data_structures.html
+++ b/libstdc++-v3/doc/html/manual/policy_data_structures.html
@@ -86,7 +86,7 @@ 
 	the source files, but the generated names for external symbols can
 	be large for binary files or debuggers.
       </p><p>
-	In many cases, the longer names allow capabilities and behaviours
+	In many cases, the longer names allow capabilities and behaviors
 	controlled by macros to also be unamibiguously emitted as distinct
 	generated names.
       </p><p>
diff --git a/libstdc++-v3/doc/html/manual/strings.html b/libstdc++-v3/doc/html/manual/strings.html
index c7a17e9..83c699c 100644
--- a/libstdc++-v3/doc/html/manual/strings.html
+++ b/libstdc++-v3/doc/html/manual/strings.html
@@ -127,7 +127,7 @@ 
       very good information.
    </p></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a id="strings.string.character_types"></a>Arbitrary Character Types</h3></div></div></div><p>
     </p><p>The <code class="code">std::basic_string</code> is tantalizingly general, in that
-      it is parameterized on the type of the characters which it holds.
+      it is parametrized on the type of the characters which it holds.
       In theory, you could whip up a Unicode character class and instantiate
       <code class="code">std::basic_string&lt;my_unicode_char&gt;</code>, or assuming
       that integers are wider than characters on your platform, maybe just
diff --git a/libstdc++-v3/include/bits/atomic_base.h b/libstdc++-v3/include/bits/atomic_base.h
index d9d755a..54bf213 100644
--- a/libstdc++-v3/include/bits/atomic_base.h
+++ b/libstdc++-v3/include/bits/atomic_base.h
@@ -255,7 +255,7 @@  _GLIBCXX_BEGIN_NAMESPACE_VERSION
    *
    *  Base type is POD with data, allowing atomic_flag to derive from
    *  it and meet the standard layout type requirement. In addition to
-   *  compatibilty with a C interface, this allows different
+   *  compatibility with a C interface, this allows different
    *  implementations of atomic_flag to use the same atomic operation
    *  functions, via a standard conversion to the __atomic_flag_base
    *  argument.
diff --git a/libstdc++-v3/include/bits/regex.h b/libstdc++-v3/include/bits/regex.h
index 58d4e72..37878f9 100644
--- a/libstdc++-v3/include/bits/regex.h
+++ b/libstdc++-v3/include/bits/regex.h
@@ -43,7 +43,7 @@  _GLIBCXX_BEGIN_NAMESPACE_VERSION
    * A regular expression traits class that satisfies the requirements of 
    * section [28.7].
    *
-   * The class %regex is parameterized around a set of related types and
+   * The class %regex is parametrized around a set of related types and
    * functions used to complete the definition of its semantics.  This class
    * satisfies the requirements of such a traits class.
    */
diff --git a/libstdc++-v3/include/bits/valarray_array.h b/libstdc++-v3/include/bits/valarray_array.h
index e04d49c..6de73b8 100644
--- a/libstdc++-v3/include/bits/valarray_array.h
+++ b/libstdc++-v3/include/bits/valarray_array.h
@@ -336,7 +336,7 @@  _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
   //
   // Compute the sum of elements in range [__f, __l)
-  // This is a naive algorithm.  It suffers from cancelling.
+  // This is a naive algorithm.  It suffers from canceling.
   // In the future try to specialize
   // for _Tp = float, double, long double using a more accurate
   // algorithm.
diff --git a/libstdc++-v3/include/ext/cast.h b/libstdc++-v3/include/ext/cast.h
index 961a962..fb220f3 100644
--- a/libstdc++-v3/include/ext/cast.h
+++ b/libstdc++-v3/include/ext/cast.h
@@ -38,7 +38,7 @@  _GLIBCXX_BEGIN_NAMESPACE_VERSION
    * These functions are here to allow containers to support non standard
    * pointer types.  For normal pointers, these resolve to the use of the
    * standard cast operation.  For other types the functions will perform
-   * the apprpriate cast to/from the custom pointer class so long as that
+   * the appropriate cast to/from the custom pointer class so long as that
    * class meets the following conditions:
    * 1) has a typedef element_type which names tehe type it points to.
    * 2) has a get() const method which returns element_type*.
diff --git a/libstdc++-v3/include/ext/concurrence.h b/libstdc++-v3/include/ext/concurrence.h
index b8b9589..0e87f1f 100644
--- a/libstdc++-v3/include/ext/concurrence.h
+++ b/libstdc++-v3/include/ext/concurrence.h
@@ -48,7 +48,7 @@  _GLIBCXX_BEGIN_NAMESPACE_VERSION
   // _S_atomic    multi-threaded code using atomic operations.
   enum _Lock_policy { _S_single, _S_mutex, _S_atomic }; 
 
-  // Compile time constant that indicates prefered locking policy in
+  // Compile time constant that indicates preferred locking policy in
   // the current configuration.
   static const _Lock_policy __default_lock_policy = 
 #ifdef __GTHREADS
diff --git a/libstdc++-v3/include/ext/mt_allocator.h b/libstdc++-v3/include/ext/mt_allocator.h
index 4d61620..1d1be40 100644
--- a/libstdc++-v3/include/ext/mt_allocator.h
+++ b/libstdc++-v3/include/ext/mt_allocator.h
@@ -185,7 +185,7 @@  _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
 
   /**
-   *  @brief  Data describing the underlying memory pool, parameterized on
+   *  @brief  Data describing the underlying memory pool, parametrized on
    *  threading support.
    */
   template<bool _Thread>
diff --git a/libstdc++-v3/testsuite/ext/pb_ds/example/hash_illegal_resize.cc b/libstdc++-v3/testsuite/ext/pb_ds/example/hash_illegal_resize.cc
index 94ca7d9..c2423bd 100644
--- a/libstdc++-v3/testsuite/ext/pb_ds/example/hash_illegal_resize.cc
+++ b/libstdc++-v3/testsuite/ext/pb_ds/example/hash_illegal_resize.cc
@@ -38,7 +38,7 @@ 
 
 /**
  * This example shows the case where a hash-based container object is
- * resized to a value which it cannot accomodate at runtime. Illegal
+ * resized to a value which it cannot accommodate at runtime. Illegal
  * runtime resizes cause an exception.
  */
 
diff --git a/libstdc++-v3/testsuite/ext/pb_ds/example/tree_intervals.cc b/libstdc++-v3/testsuite/ext/pb_ds/example/tree_intervals.cc
index d4a36c8..02716e4 100644
--- a/libstdc++-v3/testsuite/ext/pb_ds/example/tree_intervals.cc
+++ b/libstdc++-v3/testsuite/ext/pb_ds/example/tree_intervals.cc
@@ -64,7 +64,7 @@  using namespace __gnu_pbds;
 // on them. As the purpose of this example is node invariants, and not
 // computational-geometry algorithms per-se, some simplifications are
 // made (e.g., intervals are defined by unsigned integers, and not by
-// a parameterized type, data members are public, etc.).
+// a parametrized type, data members are public, etc.).
 
 // An interval of unsigned integers.
 typedef pair< unsigned int, unsigned int> interval;
diff --git a/libstdc++-v3/testsuite/util/exception/safety.h b/libstdc++-v3/testsuite/util/exception/safety.h
index 5ba9b13..9ea6ee8 100644
--- a/libstdc++-v3/testsuite/util/exception/safety.h
+++ b/libstdc++-v3/testsuite/util/exception/safety.h
@@ -1208,7 +1208,7 @@  namespace __gnu_test
 	  try
 	    {
 	      // An exception while assigning might leave the container empty
-	      // making future attemps less relevant. So we copy it before to
+	      // making future attempts less relevant. So we copy it before to
 	      // always assign to a non empty container. It also check for copy
 	      // constructor exception safety at the same time.
 	      _Tp __clone(__container);
diff --git a/libstdc++-v3/testsuite/util/testsuite_hooks.cc b/libstdc++-v3/testsuite/util/testsuite_hooks.cc
index 7f6a21e..20fedbc 100644
--- a/libstdc++-v3/testsuite/util/testsuite_hooks.cc
+++ b/libstdc++-v3/testsuite/util/testsuite_hooks.cc
@@ -237,7 +237,7 @@  namespace __gnu_test
   semaphore::semaphore() 
   {
 #ifdef _GLIBCXX_SYSV_SEM
-    // Remeber the PID for the process that created the semaphore set
+    // Remember the PID for the process that created the semaphore set
     // so that only one process will destroy the set.
     pid_ = getpid();
 
diff --git a/libstdc++-v3/testsuite/util/testsuite_hooks.h b/libstdc++-v3/testsuite/util/testsuite_hooks.h
index 48f7fa9..ecac843 100644
--- a/libstdc++-v3/testsuite/util/testsuite_hooks.h
+++ b/libstdc++-v3/testsuite/util/testsuite_hooks.h
@@ -228,7 +228,7 @@  namespace __gnu_test
   };
   
   // An class of objects that can be used for validating various
-  // behaviours and guarantees of containers and algorithms defined in
+  // behaviors and guarantees of containers and algorithms defined in
   // the standard library.
   class copy_tracker
   {