Boost logo

Boost-Commit :

Subject: [Boost-commit] svn:boost r82072 - in trunk: boost/atomic/detail libs/atomic/doc libs/atomic/test
From: tim_at_[hidden]
Date: 2012-12-18 04:43:26


Author: timblechmann
Date: 2012-12-18 04:43:23 EST (Tue, 18 Dec 2012)
New Revision: 82072
URL: http://svn.boost.org/trac/boost/changeset/82072

Log:
atomic: fix typos

fixes #7804
Text files modified:
   trunk/boost/atomic/detail/gcc-armv6plus.hpp | 2 +-
   trunk/boost/atomic/detail/gcc-ppc.hpp | 2 +-
   trunk/boost/atomic/detail/linux-arm.hpp | 2 +-
   trunk/libs/atomic/doc/atomic.hpp | 8 ++++----
   trunk/libs/atomic/doc/atomic.qbk | 8 ++++----
   trunk/libs/atomic/doc/platform.qbk | 4 ++--
   trunk/libs/atomic/test/atomicity.cpp | 2 +-
   7 files changed, 14 insertions(+), 14 deletions(-)

Modified: trunk/boost/atomic/detail/gcc-armv6plus.hpp
==============================================================================
--- trunk/boost/atomic/detail/gcc-armv6plus.hpp (original)
+++ trunk/boost/atomic/detail/gcc-armv6plus.hpp 2012-12-18 04:43:23 EST (Tue, 18 Dec 2012)
@@ -57,7 +57,7 @@
 // indicates the mode, so 1 is added to indicate that the destination code is Thumb.
 // A temporary register is needed for the address and is passed as an argument to these
 // macros. It must be one of the "low" registers accessible to Thumb code, specified
-// usng the "l" attribute in the asm statement.
+// using the "l" attribute in the asm statement.
 //
 // Architecture v7 introduces "Thumb 2", which does include (almost?) all of the ARM
 // instruction set. So in v7 we don't need to change to ARM mode; we can write "universal

Modified: trunk/boost/atomic/detail/gcc-ppc.hpp
==============================================================================
--- trunk/boost/atomic/detail/gcc-ppc.hpp (original)
+++ trunk/boost/atomic/detail/gcc-ppc.hpp 2012-12-18 04:43:23 EST (Tue, 18 Dec 2012)
@@ -48,7 +48,7 @@
     it that values carried in registers are extended appropriately and
     everything falls into place naturally).
 
- The register constrant "b" instructs gcc to use any register
+ The register constraint "b" instructs gcc to use any register
     except r0; this is sometimes required because the encoding for
     r0 is used to signify "constant zero" in a number of instructions,
     making r0 unusable in this place. For simplicity this constraint

Modified: trunk/boost/atomic/detail/linux-arm.hpp
==============================================================================
--- trunk/boost/atomic/detail/linux-arm.hpp (original)
+++ trunk/boost/atomic/detail/linux-arm.hpp 2012-12-18 04:43:23 EST (Tue, 18 Dec 2012)
@@ -14,7 +14,7 @@
 // Intel/Marvell XScale chips like the one in the NSLU2) have only atomic swap.
 // On Linux the kernel provides some support that lets us abstract away from
 // these differences: it provides emulated CAS and barrier functions at special
-// addresses that are garaunteed not to be interrupted by the kernel. Using
+// addresses that are guaranteed not to be interrupted by the kernel. Using
 // this facility is slightly slower than inline assembler would be, but much
 // faster than a system call.
 //

Modified: trunk/libs/atomic/doc/atomic.hpp
==============================================================================
--- trunk/libs/atomic/doc/atomic.hpp (original)
+++ trunk/libs/atomic/doc/atomic.hpp 2012-12-18 04:43:23 EST (Tue, 18 Dec 2012)
@@ -142,7 +142,7 @@
         implement the operation).
 
         The established memory order will be @c order if the operation
- is successful. If the operation is unsuccesful, the
+ is successful. If the operation is unsuccessful, the
         memory order will be
 
         - @c memory_order_relaxed if @c order is @c memory_order_acquire ,
@@ -162,7 +162,7 @@
         \param desired Desired new value
         \param success_order Memory ordering constraint if operation
         is successful
- \param failure_order Memory ordering constraint if operation is unsuccesful
+ \param failure_order Memory ordering constraint if operation is unsuccessful
         \return @c true if value was changed
 
         Atomically performs the following operation
@@ -215,7 +215,7 @@
         where feasible.
 
         The established memory order will be @c order if the operation
- is successful. If the operation is unsuccesful, the
+ is successful. If the operation is unsuccessful, the
         memory order will be
 
         - @c memory_order_relaxed if @c order is @c memory_order_acquire ,
@@ -235,7 +235,7 @@
         \param desired Desired new value
         \param success_order Memory ordering constraint if operation
         is successful
- \param failure_order Memory ordering constraint if operation is unsuccesful
+ \param failure_order Memory ordering constraint if operation is unsuccessful
         \return @c true if value was changed
 
         Atomically performs the following operation

Modified: trunk/libs/atomic/doc/atomic.qbk
==============================================================================
--- trunk/libs/atomic/doc/atomic.qbk (original)
+++ trunk/libs/atomic/doc/atomic.qbk 2012-12-18 04:43:23 EST (Tue, 18 Dec 2012)
@@ -115,7 +115,7 @@
 
 [section:mutex Enforcing ['happens-before] through mutual exclusion]
 
-As an introductury example to understand how arguing using
+As an introductory example to understand how arguing using
 ['happens-before] works, consider two threads synchronizing
 using a common mutex:
 
@@ -142,7 +142,7 @@
 at [^m.lock()]. If this is be thread1, then as a consequence,
 thread2 cannot succeed at [^m.lock()] before thread1 has executed
 [^m.unlock()], consequently A ['happens-before] B in this case.
-By symmetry, if thread2 suceeds at [^m.unlock()] first, we can
+By symmetry, if thread2 succeeds at [^m.unlock()] first, we can
 conclude B ['happens-before] A.
 
 Since this already exhausts all options, we can conclude that
@@ -628,7 +628,7 @@
 from C++11 as faithfully as possible, there are a few
 limitations that cannot be lifted without compiler support:
 
-* [*Using non-POD-classes as template paramater to `atomic<T>` results
+* [*Using non-POD-classes as template parameter to `atomic<T>` results
   in undefined behavior]: This means that any class containing a
   constructor, destructor, virtual methods or access control
   specifications is not a valid argument in C++98. C++11 relaxes
@@ -666,7 +666,7 @@
   of [*Boost.Atomic] compiles and has correct value semantics.
 * [*native_api.cpp] verifies that all atomic operations have correct
   value semantics (e.g. "fetch_add" really adds the desired value,
- returing the previous). It is a rough "smoke-test" to help weed
+ returning the previous). It is a rough "smoke-test" to help weed
   out the most obvious mistakes (for example with overflow,
   signed/unsigned extension, ...).
 * [*lockfree.cpp] verifies that the [*BOOST_ATOMIC_*_LOCKFREE] macros

Modified: trunk/libs/atomic/doc/platform.qbk
==============================================================================
--- trunk/libs/atomic/doc/platform.qbk (original)
+++ trunk/libs/atomic/doc/platform.qbk 2012-12-18 04:43:23 EST (Tue, 18 Dec 2012)
@@ -68,7 +68,7 @@
   Some amount of care must be taken as the "raw" data type
   passed in from the user through [^boost::atomic<T>]
   is visible here -- it thus needs to be type-punned or otherwise
- manipulated byte-by-byte to avoid using overloaded assigment,
+ manipulated byte-by-byte to avoid using overloaded assignment,
   comparison operators and copy constructors.
 
 [endsect]
@@ -302,7 +302,7 @@
 [section:platform_atomic_puttogether Putting it altogether]
 
 The template specializations should be put into a header file
-in the [^boost/atomic/detail] directory, preferrably
+in the [^boost/atomic/detail] directory, preferably
 specifying supported compiler and architecture in its name.
 
 The file [^boost/atomic/detail/platform.hpp] must

Modified: trunk/libs/atomic/test/atomicity.cpp
==============================================================================
--- trunk/libs/atomic/test/atomicity.cpp (original)
+++ trunk/libs/atomic/test/atomicity.cpp 2012-12-18 04:43:23 EST (Tue, 18 Dec 2012)
@@ -21,7 +21,7 @@
 // we get 0.995 probability to detect a race (if there is one).
 //
 // Overall this yields 0.995 * 0.995 > 0.99 confidence that the
-// operations truely behave atomic if this test program does not
+// operations truly behave atomic if this test program does not
 // report an error.
 
 #include <algorithm>


Boost-Commit list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk