From a7c3889fa95f1af20db5e691eeb2eb97415bf88f Mon Sep 17 00:00:00 2001
From: tho <tho@wiback.org>
Date: Fri, 2 Mar 2007 17:38:38 +0000
Subject: [PATCH] fixed some documentation typos
---
Mainpage.dox | 16 +++++++-------
Packets/Packet.hh | 30 +++++++++++++-------------
Packets/PacketRegistry.hh | 8 +++----
Packets/ParseListS.hh | 2 +-
Packets/ParserBase.hh | 4 ++--
Scheduler/ReadHelper.hh | 8 +++----
Scheduler/Scheduler.hh | 16 +++++++-------
Scheduler/WriteHelper.hh | 8 +++----
Socket/BSDSocketProtocol.hh | 4 ++--
Socket/ClientSocketHandle.hh | 12 +++++------
Socket/CommunicationPolicy.hh | 6 +++---
Socket/FileHandle.hh | 12 +++++------
Socket/FileHandle.ih | 2 +-
Socket/GenericAddressingPolicy.hh | 6 +++---
Socket/GenericSockAddr.hh | 4 ++--
Socket/INetAddressing.hh | 14 ++++++------
Socket/INetProtocol.hh | 12 +++++------
Socket/LLAddressing.hh | 6 +++---
Socket/ReadWritePolicy.hh | 4 ++--
Socket/SocketHandle.hh | 6 +++---
Socket/SocketPolicy.hh | 36 +++++++++++++++----------------
Socket/SocketProtocol.hh | 6 +++---
Utils/DaemonTools.hh | 4 ++--
Utils/Exception.hh | 6 +++---
Utils/Logger.hh | 8 +++----
Utils/MicroTime.hh | 2 +-
Utils/SafeBool.hh | 2 +-
Utils/intrusive_refcount.hh | 2 +-
Utils/membind.hh | 2 +-
senfscons/Mainpage.dox | 4 ++--
30 files changed, 126 insertions(+), 126 deletions(-)
diff --git a/Mainpage.dox b/Mainpage.dox
index 19a6d1f37..b4b8b00ef 100644
--- a/Mainpage.dox
+++ b/Mainpage.dox
@@ -53,7 +53,7 @@
oriented and template based. For compatibility reasons, the libraries are therefore built
together with every project making use of the framework.
- When starting a new Projekt based on the SENF framework, it is advisable, to make use of the
+ When starting a new project based on the SENF framework, it is advisable, to make use of the
SENFSCons build environment and use SVN to manage the code repository. This is the
configuration, described in this documentation.
@@ -64,7 +64,7 @@
\section Preliminaries
- Before starting the devlopment, make sure to fulfill the following requirements:
+ Before starting the development, make sure to fulfill the following requirements:
\li GNU g++, version at least 3.4
\li The Boost libraries (http://www.boost.org)
@@ -145,7 +145,7 @@
\section libPackets libPackets: Network packet manipulation
- This libarary provides a very flexible infrastructure to parse, create and otherwise manipulate
+ This library provides a very flexible infrastructure to parse, create and otherwise manipulate
packetized network data. Included is a library of several protocol parsers covering the basic
IPv4 and IPv6 network protocols down to the Ethernet layer.
@@ -207,7 +207,7 @@
You now have to decide, which modules you want to use. Every module resides in it's own
subdirectory in the SENF repository. Instead of directly checking out the code, we will use \c
- svn:externals. This will instruct \c svn to auutomatically check out the needed directories from
+ svn:externals. This will instruct \c svn to automatically check out the needed directories from
the BerliOS SENF repository. Change to the 'Foo' directory and type
<pre>
@@ -216,7 +216,7 @@
The default editor (probably VI) will be started with the current value of the svn:externals
property (which will probably be empty). Now add all the modules you want plus \c senfscons and
- possibly \c doclib (if you want to build the documentation). You will almost certainly neeed the
+ possibly \c doclib (if you want to build the documentation). You will almost certainly need the
\c Utils module, since all other modules depend on it.
For example, if you want to use the \c Scheduler and \c Socket module, the file will look like
@@ -240,7 +240,7 @@
To set up the build environment, copy the <tt>senfscons/SConstruct.template</tt> to
<tt>SConstruct</tt> in the project root. The default setup of this file is to build all
- subdirectories (using the \c SConscript files of the subdirectories). You can add additonal
+ subdirectories (using the \c SConscript files of the subdirectories). You can add additional
global targets and configuration parameters here.
If you want to use a non-default compiler or the boost library is not installed in the system
@@ -264,7 +264,7 @@
$ scons
</pre>
- If you have not changed the \c SConstruct file, this will build all modules you have importet
+ If you have not changed the \c SConstruct file, this will build all modules you have imported
into your project. To build and execute the unit tests, use
<pre>
@@ -363,7 +363,7 @@
<tr><td>\c .cci</td><td>C++ implementation of inline non-template functions and
members</td></tr>
- <tr><td>\c .cti</td><td>C++ implementation of inline template fuanctions and members</td></tr>
+ <tr><td>\c .cti</td><td>C++ implementation of inline template functions and members</td></tr>
<tr><td>\c .mpp</td><td>Special include file used for external iteration by the
Boost.Preprocessor library</td></tr> </table>
diff --git a/Packets/Packet.hh b/Packets/Packet.hh
index 39b9c250c..dd913d6a5 100644
--- a/Packets/Packet.hh
+++ b/Packets/Packet.hh
@@ -37,7 +37,7 @@
\todo Implement special container replacing vector which manages
some headroom to allow efficient insertion of elements at the
- beginning. This really is just another type of deque
+ beginning. This really is just another type of dequeue
implementation.
*/
@@ -68,7 +68,7 @@ namespace senf {
This class is the base class of all Packets. It implements the
generic Packet interface and provides the packet management
framework. senf::Packet manages the necessary memory
- resources and controlls the chain of packet interpreters.
+ resources and controls the chain of packet interpreters.
The Packet user always interfaces with the pkf via a Packet
derived class. This is the only external entity ever held by a
@@ -81,7 +81,7 @@ namespace senf {
Internally, every Packet references a PacketImpl instance which
manages the raw packet data and the interpreter list. This raw
data is interpreted by the concrete Packet derived class
- according to the definition of that derived class's packet
+ according to the definition of that derived classes packet
type (i.e. EthernetPacket or UDPPacket).
Packet provides several interfaces:
@@ -157,7 +157,7 @@ namespace senf {
senf:PacketRegistry, it must not take any additional
constructor parameters.
- After having implemented the bare framework, the most comman
+ After having implemented the bare framework, the most common
way to implement access to the packets specific data is to use
the parser framework by additionally inheriting a
corresponding parser. This also automatically implements the
@@ -224,9 +224,9 @@ namespace senf {
The Packet interface is implemented to minimize overhead as
far as possible without getting to complex. One area for
- improvement ist the container class used to hold the raw
+ improvement is the container class used to hold the raw
data. This currently is an \a std::vector. This could be
- imporved by either allocating some headroom/tailroom in the
+ improved by either allocating some headroom/tailroom in the
vector and using this when inserting data at the beginning or
end. Alternatively, a new container class (like the
senf::deque_list) could be used to support zero-copy
@@ -241,7 +241,7 @@ namespace senf {
we cannot construct the \a writev() data structures.
The interpreter list managed by Packet is lazy, meaning packet
- interpreter facades are added only when requestd by next(),
+ interpreter facades are added only when requested by next(),
last() or find_next(). v_nextInterpreter() is called if
necessary by these methods to complete the interpreter chain.
@@ -255,7 +255,7 @@ namespace senf {
interpreter list to the Packet facades must not be
counted. They are therefore implemented differently (
boost::shared_ptr vs. boost::intrusive_ptr). The choice of
- boost::intrusive_ptr for the externaly visible smart pointer
+ boost::intrusive_ptr for the externally visible smart pointer
for all Packet facades is taken to reduce the overhead (an
intrusive_ptr is only the size of an ordinary pointer, a
smart_ptr has the size of two pointers).
@@ -333,7 +333,7 @@ namespace senf {
\param e corresponding end iterator
\return smart pointer to new packet
\throws TruncatedPacketException The data cannot be parsed
- securely (the data might be trunctated or just
+ securely (the data might be truncated or just
plain invalid)
*/
template <class OtherPacket, class InputIterator>
@@ -381,8 +381,8 @@ namespace senf {
OtherPacket. \e Assert's, that a packet of this type exists */
template <class OtherPacket> typename ptr_t<OtherPacket>::ptr get_prev() const;
- /** \brief check, wether the packet is of the given type
- \return true, if packt is of type \a OtherPacket, false
+ /** \brief check, whether the packet is of the given type
+ \return true, if packet is of type \a OtherPacket, false
otherwise */
template <class OtherPacket> bool is() const;
/** \brief cast packet pointer to the given type
@@ -402,7 +402,7 @@ namespace senf {
\return smart pointer to a \e new packet facade
\throws TruncatedPacketException there is not enough data
- to savely interpret the packet as the given type. The
+ to safely interpret the packet as the given type. The
original packet is \e not invalidated
*/
template <class OtherPacket>
@@ -413,7 +413,7 @@ namespace senf {
///\name Raw packet data
///@{
- /** \brief begin interator of raw packet data
+ /** \brief begin iterator of raw packet data
This iterator allows access to the raw data interpreted by
the packet facade. This \e includes any header possibly
@@ -526,10 +526,10 @@ namespace senf {
This method is called by the packet framework to let the
interpreter facade do some final calculations/packet
cleanup before the packet is sent out or digested in some
- other way. This is the place to calcaulate checksums and
+ other way. This is the place to calculate checksums and
such.
- This method is autmatically called for all interpreters on
+ This method is automatically called for all interpreters on
the interpreter chain.
*/
virtual void v_finalize() = 0;
diff --git a/Packets/PacketRegistry.hh b/Packets/PacketRegistry.hh
index d5bc480cc..93f951aa3 100644
--- a/Packets/PacketRegistry.hh
+++ b/Packets/PacketRegistry.hh
@@ -50,7 +50,7 @@ namespace senf {
typedef some_key_type key_t;
};
\endcode
- The key type can be an arbitrary valuetype. The PacketRegistry
+ The key type can be an arbitrary value type. The PacketRegistry
for this Tag can then be accessed using
<code>PacketRegistry<SomeTag>::</code>.
@@ -109,7 +109,7 @@ namespace senf {
any other packet class in this registry.
The Packet must not already be registered in the registry.
- \param OtherPacket packet to regiser
+ \param OtherPacket packet to register
\param key key of the packet
*/
template <class OtherPacket>
@@ -132,7 +132,7 @@ namespace senf {
\param key Key of packet type to create instance of
\param b begin iterator argument to Packet::create()
- \param e end iterator argment to Packet::create()
+ \param e end iterator argument to Packet::create()
\returns new Instance of the packet type registered under
key or DataPacket, if the key is not registered.
*/
@@ -154,7 +154,7 @@ namespace senf {
This mixin class provides a new registerInterpreter
implementation which can be used besides the methods provided
- bei senf::Packet to add a new interpreter to the
+ by senf::Packet to add a new interpreter to the
interpreter chain.
\code
diff --git a/Packets/ParseListS.hh b/Packets/ParseListS.hh
index 98517a8cb..63d3ff1c8 100644
--- a/Packets/ParseListS.hh
+++ b/Packets/ParseListS.hh
@@ -26,7 +26,7 @@
transition function. See ParseListS.hh for more.
We should write a baseclass for sentinels which has no \c check()
- member, en empty \c next() member and \c void as the state
+ member, an empty \c next() member and \c void as the state
type. This simplifies writing simple sentinels.
The parse_listS iterator will have to pass the state in addition
diff --git a/Packets/ParserBase.hh b/Packets/ParserBase.hh
index d9c3723aa..6cf4f8e73 100644
--- a/Packets/ParserBase.hh
+++ b/Packets/ParserBase.hh
@@ -107,7 +107,7 @@ namespace senf {
// return true, if the data in the range [begin,end)
// can be safely interpreted by the parser without
// causing invalid memory access. This means,
- // check, wether the data is truncated
+ // check, whether the data is truncated
return static_cast<unsigned>(end-begin) >= bytes();
}
@@ -271,7 +271,7 @@ namespace senf {
/** \brief Addtiional Parser information
- Parser_traits provids abstract information about an unknown
+ Parser_traits provides abstract information about an unknown
parser. Besides the information already available within the
Parser it provides an additional 'fixed_sized' member which is
true if and only if the Parser has a static bytes() member.
diff --git a/Scheduler/ReadHelper.hh b/Scheduler/ReadHelper.hh
index d1393ad3b..c4fbbc8fb 100644
--- a/Scheduler/ReadHelper.hh
+++ b/Scheduler/ReadHelper.hh
@@ -42,7 +42,7 @@ namespace senf {
/** \brief Asyncronous reading helper
This class provides a simple asynchronous reading facility. This helper will register with
- the Scheduler and read incoming data. It will collect the data until a specific numbner of
+ the Scheduler and read incoming data. It will collect the data until a specific number of
bytes has been read or some Predicate evaluated on the data read thus far signals end of
data.
@@ -58,7 +58,7 @@ namespace senf {
The predicate is any class instance with an <tt>operator(std::string const &)</tt>. This
operator is called, whenever some data has been read. If the data is not yet complete, the
- predicate must return \c std::string::npos. If the ReadHelper should stop readeing more
+ predicate must return \c std::string::npos. If the ReadHelper should stop reading more
data, the predicate must return the number of bytes which are to be considered 'matched'.
\todo Move all not Handle dependent members to a ReadHandleBase class
@@ -118,9 +118,9 @@ namespace senf {
std::string const & data() const; ///< return data read
std::string const & tail() const; ///< return data read but not matched by the predicate
- bool complete() const; ///< Check wether the read has completed successfully
+ bool complete() const; ///< Check whether the read has completed successfully
bool error() const; ///< Check for error condition
- void throw_error() const; ///< If an error occured, throw it
+ void throw_error() const; ///< If an error occurred, throw it
void revoke(); ///< Remove the ReadHelper from the scheduler
diff --git a/Scheduler/Scheduler.hh b/Scheduler/Scheduler.hh
index a2f96daa3..aac4671a6 100644
--- a/Scheduler/Scheduler.hh
+++ b/Scheduler/Scheduler.hh
@@ -45,7 +45,7 @@ namespace senf {
/** \brief Singleton class to manage the event loop
This class manages a single select() type event loop. A customer of this class may register
- any number of file descriptiors with this class and pass callback functions to be called on
+ any number of file descriptors with this class and pass callback functions to be called on
input, output or error. This functions are specified using boost::function objects (See <a
href="http://www.boost.org/doc/html/function.html">Boost.Function</a>)
@@ -54,16 +54,16 @@ namespace senf {
\code
int fd = retrieve_filehandle(object);
\endcode
- is valid and places the relevent file descriptor into fd can be used as a Handle type. There
+ is valid and places the relevant file descriptor into fd can be used as a Handle type. There
is an implementation of retrieve_filehandle(int) within the library to handle explicit file
- descrptors. The <a href="../../../Socket/doc/html/index.html">Socket library</a> provides an
- implementation of <tt>retrive_filehandle(FileHandle handle)</tt>. If you want to support
- some other handle type, just define an apropriate \c retrieve_filehandle function <em>in
+ descriptors. The <a href="../../../Socket/doc/html/index.html">Socket library</a> provides an
+ implementation of <tt>retrieve_filehandle(FileHandle handle)</tt>. If you want to support
+ some other handle type, just define an appropriate \c retrieve_filehandle function <em>in
that types namespace</em>.
It is important to note, that for every combination of file descriptor and event, only a \e
single handler may be installed. Installing more handlers does not make sense. If you need
- to distribute data to serveral interested parties, you must take care of this yourself.
+ to distribute data to several interested parties, you must take care of this yourself.
\todo Fix EventId parameter (probably to int) to allow |-ing without casting ...
*/
@@ -111,7 +111,7 @@ namespace senf {
time
\implementation This static member just defines the Scheduler as a static method
- variable. The C++ standard then provides above guaratee. The instance will be
+ variable. The C++ standard then provides above guarantee. The instance will be
initialized the first time, the code flow passes the variable declaration found in
the instance() body.
*/
@@ -125,7 +125,7 @@ namespace senf {
typename GenericCallback<Handle>::Callback const & cb,
int eventMask = EV_ALL); ///< Add file handle event callback
/**< add() will add a callback to the Scheduler. The
- callbeck will be called for the given type of event on
+ callback will be called for the given type of event on
the given arbitrary file-descriptor or
handle-like object. If there already is a Callback
register ed for one of the events requested, the new
diff --git a/Scheduler/WriteHelper.hh b/Scheduler/WriteHelper.hh
index 862ef80fc..998ae79f7 100644
--- a/Scheduler/WriteHelper.hh
+++ b/Scheduler/WriteHelper.hh
@@ -38,8 +38,8 @@ namespace senf {
/** \brief Asyncronous writing helper
- This class provides a simple asyncronous writing facility. This helper will register with
- the Scheduler to write the requested data. It will stay registered until the data has benen
+ This class provides a simple asynchronous writing facility. This helper will register with
+ the Scheduler to write the requested data. It will stay registered until the data has been
completely sent or some error condition is encountered. As soon as the WriteHelper is done,
the callback will be called.
@@ -86,9 +86,9 @@ namespace senf {
an empty string. Until then, the complete string will
be returned. */
- bool complete() const; ///< Check wether the write has completed successfully
+ bool complete() const; ///< Check whether the write has completed successfully
bool error() const; ///< Check for error condition
- void throw_error() const; ///< If an error occured, throw it
+ void throw_error() const; ///< If an error occurred, throw it
void revoke(); ///< Remove the WriteHelper from the scheduler
diff --git a/Socket/BSDSocketProtocol.hh b/Socket/BSDSocketProtocol.hh
index 9219dff67..bfdef2b0a 100644
--- a/Socket/BSDSocketProtocol.hh
+++ b/Socket/BSDSocketProtocol.hh
@@ -56,7 +56,7 @@ namespace senf {
/**< If linger is enabled, the timeout value specifies, how
long to wait before returning while data is unsent in
seconds. If this value is 0, a close() might wait
- forvever.
+ forever.
\param[in] enable \c true to activate linger
\param[in] timeout linger timeout in seconds */
@@ -68,7 +68,7 @@ namespace senf {
\returns timestamp when packet was received */
};
- /** \brief Protocol facat providing basic connection oriented BSD socket functions
+ /** \brief Protocol facet providing basic connection oriented BSD socket functions
AddressableBSDSocketProtocol provides the BSD socket API as it generically applies to
addressable (connection oriented) sockets.
diff --git a/Socket/ClientSocketHandle.hh b/Socket/ClientSocketHandle.hh
index 319696795..f5e27160b 100644
--- a/Socket/ClientSocketHandle.hh
+++ b/Socket/ClientSocketHandle.hh
@@ -144,7 +144,7 @@ namespace senf {
that the socket buffer will be empty after read() returns.
\attention If the space available for the data read is limited, the read will return no
- more than that amount of data. For a datagram socket, a full datagram is still dequed
+ more than that amount of data. For a datagram socket, a full datagram is still dequeued
from the socket buffer, the remainder of the datagram will be lost.
There are three variants of read which differ in how they return the read string.
@@ -175,7 +175,7 @@ namespace senf {
now. If you do not want to block, you \e must make the
socket non-blocking (using FileHandle::blocking()).
\param[out] buffer data read
- \param[in] limit Maximum number of buytes to read or 0
+ \param[in] limit Maximum number of bytes to read or 0
if unlimited
\see \ref read() */
unsigned read (char * buffer, unsigned size);
@@ -216,12 +216,12 @@ namespace senf {
\param[out] from peer address
\see \ref readfrom() */
unsigned readfrom (char * buffer, unsigned size, Address & from);
- ///< Read data into memory byffer
+ ///< Read data into memory buffer
/**< This variant will read data into the memory area at \c
buffer of size \c size. This is the most performant
version of readfrom().
\param[in] buffer address of buffer to store data at
- \param[in] size size of bnuffer
+ \param[in] size size of buffer
\param[out] from peer address
\returns Number of bytes read
\see \ref readfrom() */
@@ -235,7 +235,7 @@ namespace senf {
A single write call might depending on the circumstances write only part of the data.
- There are two variants of thie member
+ There are two variants of this member
\throws senf::SystemException
@@ -276,7 +276,7 @@ namespace senf {
unsigned writeto (AddressParam addr, std::string const & data);
unsigned writeto (AddressParam addr, char const * buffer, unsigned size);
///< Write data from memory buffer to unconnected socket
- /**< \param[in] addr Address o fpeer to send data to
+ /**< \param[in] addr Address of peer to send data to
\param[in] buffer address of buffer to write
\param[in] size amount of data to write
\returns Number of bytes written
diff --git a/Socket/CommunicationPolicy.hh b/Socket/CommunicationPolicy.hh
index 11c9af117..fe899262f 100644
--- a/Socket/CommunicationPolicy.hh
+++ b/Socket/CommunicationPolicy.hh
@@ -56,8 +56,8 @@ namespace senf {
/**< \param[in] handle socket handle to enable reception on
\param[in] backlog size of backlog queue
- \fixme listen probably makes no sense without accpept,
- so listen() should debend on AddressingPolicy
+ \fixme listen probably makes no sense without accept,
+ so listen() should depend on AddressingPolicy
too. */
template <class Policy>
static int accept(ServerSocketHandle<Policy> handle,
@@ -82,7 +82,7 @@ namespace senf {
This is different from UndefinedCommunicationPolicy (which is the same as
CommunicationPolicyBase). This policy class defines the communication policy -- it
explicitly states, that the socket does not support connected communication. This
- effektively disables ther ServerSocketHandle.
+ effectively disables the ServerSocketHandle.
*/
struct UnconnectedCommunicationPolicy : public CommunicationPolicyBase
{};
diff --git a/Socket/FileHandle.hh b/Socket/FileHandle.hh
index 79985c473..303916b53 100644
--- a/Socket/FileHandle.hh
+++ b/Socket/FileHandle.hh
@@ -87,10 +87,10 @@ namespace senf {
not readable or writable or only using special function calls like sendto).
The FileHandle class provides handle/body handling and uses automatic reference
- counting. The senf::FileHandle istance is very lightweight and should be used like a
+ counting. The senf::FileHandle instance is very lightweight and should be used like a
built-in type.
- \attention You should mostly pass around senf::FileHandle objects by \e value und not by
+ \attention You should mostly pass around senf::FileHandle objects by \e value and not by
reference.
The FileHandle abstraction is only applicable to real filehandles. It is \e not possible to
@@ -105,7 +105,7 @@ namespace senf {
\section filehandle_new Writing senf::FileHandle derived classes
To build a new FileHandle type you need to derive from senf::FileHandle. The derived class
- will have to call the protocted FileHandle constructor passing a new senf::FileBody
+ will have to call the protected FileHandle constructor passing a new senf::FileBody
instance. This instance may either be a simple senf::FileBody or a class derived from
senf::FileBody.
@@ -137,11 +137,11 @@ namespace senf {
/**< \throws senf::SystemException */
void terminate(); ///< Close filehandle ignoring error conditions
- bool readable() const; ///< Check, wether a read on the handle would not block
+ bool readable() const; ///< Check, whether a read on the handle would not block
///< (ignoring blocking state)
void waitReadable() const; ///< Wait, until read on the handle would not block (ignoring
///< blocking state)
- bool writeable() const; ///< Check, wether a write on the handle would not block
+ bool writeable() const; ///< Check, whether a write on the handle would not block
///< (ignoring blocking state)
void waitWriteable() const; ///< Wait, until a write on the handle would not block
///< (ignoring blocking state)
@@ -163,7 +163,7 @@ namespace senf {
FileHandle */
bool boolean_test() const; ///< Short for valid() && ! eof()
- /**< This is called when using a FileHandle instance in a boolen
+ /**< This is called when using a FileHandle instance in a boolean
context
See the performance comments for the eof() member */
diff --git a/Socket/FileHandle.ih b/Socket/FileHandle.ih
index 25b45c72f..b297f0597 100644
--- a/Socket/FileHandle.ih
+++ b/Socket/FileHandle.ih
@@ -56,7 +56,7 @@ namespace senf {
pointing to a different body type).
To customize the behavior, a virtual interface is provided. This interface only covers some
- basic funcionality which is only used infrequently during the lifetime of a FileHandle
+ basic functionality which is only used infrequently during the lifetime of a FileHandle
instance.
*/
diff --git a/Socket/GenericAddressingPolicy.hh b/Socket/GenericAddressingPolicy.hh
index 7eeed123d..f842d2b47 100644
--- a/Socket/GenericAddressingPolicy.hh
+++ b/Socket/GenericAddressingPolicy.hh
@@ -41,7 +41,7 @@ namespace senf {
/// \addtogroup policy_impl_group
/// @{
- /** \brief Non-template implemenatation class of GenericAddressingPolicy template
+ /** \brief Non-template implementation class of GenericAddressingPolicy template
\internal
*/
@@ -74,8 +74,8 @@ namespace senf {
members. sockaddr_p could always return a const * whereas open_sockaddr_p should return a
non-const pointer. The close operation would then explicitly signal, that the new value
should be incorporated into the class. With our current implementation, the close member
- would be a no-op, however this ould free us from using the sockaddr values as a direct
- sotrage representation of the address.
+ would be a no-op, however this should free us from using the sockaddr values as a direct
+ storage representation of the address.
*/
template <class Address>
struct GenericAddressingPolicy
diff --git a/Socket/GenericSockAddr.hh b/Socket/GenericSockAddr.hh
index a5cea03fd..8161c80a7 100644
--- a/Socket/GenericSockAddr.hh
+++ b/Socket/GenericSockAddr.hh
@@ -74,11 +74,11 @@ namespace senf {
address interface.
\returns non-const (!) pointer to sockaddr structure */
struct sockaddr const * sockaddr_p() const; ///< Return a pointer to sockaddr structure
- /**< This member is like sockaddr_p(), hoewever it does not
+ /**< This member is like sockaddr_p(), however it does not
allow changing the address.
\returns const pointer to sockaddr structure */
unsigned sockaddr_len() const; ///< Return size of address
- /**< This meember return the size of the socket address
+ /**< This member return the size of the socket address
structure as returned by sockaddr_p() in bytes.
\returns size of respective sockaddr structure in bytes
*/
diff --git a/Socket/INetAddressing.hh b/Socket/INetAddressing.hh
index d9ff2a7a1..de661cbd1 100644
--- a/Socket/INetAddressing.hh
+++ b/Socket/INetAddressing.hh
@@ -46,8 +46,8 @@ namespace senf {
/** \brief IPv4 socket address
- INet4Address wrapps the standard sockaddr_in datatype. It provides simple accessor methods
- to accss the host and port. It does \e not integrate \c gethostbyname or DNS lookup.
+ INet4Address wraps the standard sockaddr_in datatype. It provides simple accessor methods
+ to access the host and port. It does \e not integrate \c gethostbyname or DNS lookup.
\todo Implement real INet4Address datatype and rename this one to INet4SockAddress ...
\todo Implement more complete interface
@@ -111,7 +111,7 @@ namespace senf {
numeric string representations of IPv6 addresses. This class does not integrate with \c
gethostbyname() and so does not support host names.
- The conversion constructors allow the use of string constants whereever an INet6Address is
+ The conversion constructors allow the use of string constants wherever an INet6Address is
expected. Especially, it is possible to assign a string to an address to change it's value.
\implementation The <tt>char const *</tt> constructor overload is needed to support
@@ -173,7 +173,7 @@ namespace senf {
/** \brief IPv6 socket address
- This class wrapps the standard \c sockaddr_in6 structure. INet6SocketAddress provides access
+ This class wraps the standard \c sockaddr_in6 structure. INet6SocketAddress provides access
to all members of the sockaddr_in6 structure. Additionally, INet6SocketAddress supports the
string representation
@@ -219,7 +219,7 @@ namespace senf {
INet6SocketAddress(); ///< Create empty instance
INet6SocketAddress(std::string const & addr);
- ///< Initialize/convert from string represenation
+ ///< Initialize/convert from string representation
INet6SocketAddress(char const * addr); ///< Same as above to support string literals
INet6SocketAddress(INet6Address const & addr, unsigned port);
///< Initialize from address and port
@@ -290,7 +290,7 @@ namespace senf {
This addressing policy implements addressing using Internet V4
addresses.
- The various members are directly importet from
+ The various members are directly imported from
GenericAddressingPolicy which see for a detailed
documentation.
*/
@@ -314,7 +314,7 @@ namespace senf {
This addressing policy implements addressing using Internet V6
addresses.
- The various members are directly importet from
+ The various members are directly imported from
GenericAddressingPolicy which see for a detailed
documentation.
*/
diff --git a/Socket/INetProtocol.hh b/Socket/INetProtocol.hh
index d4f051cf8..5145be0c0 100644
--- a/Socket/INetProtocol.hh
+++ b/Socket/INetProtocol.hh
@@ -53,14 +53,14 @@ namespace senf {
addressing.
\todo Is it safe, not to allow setting the interface index on add/drop? what does it do
- (especially if the local addres is given ?). What have I been thinking here ???
+ (especially if the local address is given ?). What have I been thinking here ???
\todo move all multicast-methods into an extra IPv4MulticastProtocol class (it's only
available on datagram sockets)
\todo the multicast add/remove/iface semantics are quite unclear ...
- \todo connect() is only available on stream sockets. We want to access bind() and connet()
+ \todo connect() is only available on stream sockets. We want to access bind() and connect()
via the ClientSocketHandle -> see SocketProtocol todo point
*/
class IPv4Protocol
@@ -89,7 +89,7 @@ namespace senf {
interface.
\param[in] mcAddr address of group to join
\todo fix this as soon as we have a real address class
- (differend from the sockaddress class */
+ (different from the sockaddress class */
void mcAddMembership(INet4Address const & mcAddr, INet4Address const & localAddr) const;
///< join multicast group on a specific address/interface
/**< This member will add \a mcAddr to the list of multicast
@@ -98,7 +98,7 @@ namespace senf {
\param[in] mcAddr address of group to join
\param[in] localAddr address of interface to join on
\todo fix this as soon as we have a real address class
- (differend from the sockaddress class */
+ (different from the sockaddress class */
void mcDropMembership(INet4Address const & mcAddr) const;
///< Leave multicast group
@@ -107,7 +107,7 @@ namespace senf {
default interface.
\param[in] mcAddr address of group to leave
\todo fix this as soon as we have a real address class
- (differend from the sockaddress class */
+ (different from the sockaddress class */
void mcDropMembership(INet4Address const & mcAddr, INet4Address const & localAddr) const;
///< leave multicast group on a specific address/interface
/**< This member will remove \a mcAddr from the list of
@@ -116,7 +116,7 @@ namespace senf {
\param[in] mcAddr address of group to leave
\param[in] localAddr address of interface to leave from
\todo fix this as soon as we have a real address class
- (differend from the sockaddress class */
+ (different from the sockaddress class */
void mcIface(std::string iface = std::string()) const;
///< set default multicast interface of the socket
diff --git a/Socket/LLAddressing.hh b/Socket/LLAddressing.hh
index d562a29b1..cedd2a038 100644
--- a/Socket/LLAddressing.hh
+++ b/Socket/LLAddressing.hh
@@ -50,7 +50,7 @@ namespace senf {
/** \brief Link local address
- LLSocketAddress wrapps the standard sockaddr_ll datatype.
+ LLSocketAddress wraps the standard sockaddr_ll datatype.
\todo I don't think the current implementation is
sensible. I'll have to reimplement this class probably
@@ -60,7 +60,7 @@ namespace senf {
'ForwardRange' representation for a raw ll
address (See <a
href="http://www.boost.org/libs/range/index.html">Boost.Range</a>).
- This representation allows zero-copy imlementations of
+ This representation allows zero-copy implementations of
many operations, however it is probably not worth the
effort since the ll address is restricted to a max of 8
bytes. Therefore this will be changed and the concrete
@@ -73,7 +73,7 @@ namespace senf {
// as the representation for a hardware address. The restrictions
// for the range are:
// a) the range must never be larger than 8 elements
- // b) the value_type must be convertible to unsigend char
+ // b) the value_type must be convertible to unsigned char
// and really we need only a single-pass range.
//
// Since a hardware address is so short (a maximum of 8
diff --git a/Socket/ReadWritePolicy.hh b/Socket/ReadWritePolicy.hh
index 00ab590dd..552b8739c 100644
--- a/Socket/ReadWritePolicy.hh
+++ b/Socket/ReadWritePolicy.hh
@@ -48,7 +48,7 @@ namespace senf {
/** \brief ReadPolicy for readable sockets
This policy provides support for readable sockets via the standard UNIX read/recvfrom system
- cals. The concreate semantics of the read calls depend on the framing policy of the socket.
+ calls. The concrete semantics of the read calls depend on the framing policy of the socket.
*/
struct ReadablePolicy : public ReadPolicyBase
{
@@ -86,7 +86,7 @@ namespace senf {
/** \brief WritePolicy for writeable sockets
This policy provides support for writable sockets via the standard UNIX write/sendto system
- cals. The concreate semantics of the write calls depend on the framing policy of the socket.
+ calls. The concrete semantics of the write calls depend on the framing policy of the socket.
*/
struct WriteablePolicy : public WritePolicyBase
{
diff --git a/Socket/SocketHandle.hh b/Socket/SocketHandle.hh
index 6cb2c4be3..3f3f88ca5 100644
--- a/Socket/SocketHandle.hh
+++ b/Socket/SocketHandle.hh
@@ -112,7 +112,7 @@ namespace senf {
void state(SocketStateMap & map, unsigned lod=0);
///< Inquire state information of socket handle
/**< The map argument (a string to string mapping) will be
- filled with information coverning the current state of
+ filled with information covering the current state of
the socket. The information provided depends on the
socket protocol. The amount of information returned can
be controlled using the \p lod value.
@@ -122,7 +122,7 @@ namespace senf {
\param map string to string mapping to be filled with
state information
- \param lod level of detail requesten. The interpretation
+ \param lod level of detail requested. The interpretation
of this value is protocol specific
\implementation This member will be re-implemented in
@@ -231,7 +231,7 @@ namespace senf {
/** \brief dynamically check cast validity
- This function will check, wether the given cast is valid. This is the same as checking, that
+ This function will check, whether the given cast is valid. This is the same as checking, that
dynamic_socket_cast does not throw.
This member is needed, since there is no 'null' SocketHandle (comparable to a null pointer)
diff --git a/Socket/SocketPolicy.hh b/Socket/SocketPolicy.hh
index 78311f14f..8784edd92 100644
--- a/Socket/SocketPolicy.hh
+++ b/Socket/SocketPolicy.hh
@@ -72,7 +72,7 @@
this Unspecified type, the axis is left unspecified, the concrete policy will be incomplete.
The senf::SocketPolicy template defines the behavior of a socket handle. The socket handle
- instances do not implement any socket functionality themselves instead defering the
+ instances do not implement any socket functionality themselves instead deferring the
implementation to the policy classes. The SocketHandle interface is therefore \e not implemented
using virtual members, all important socket functions can be inlined by the compiler to create
highly efficient code.
@@ -80,7 +80,7 @@
A senf::SocketPolicy instance can be incomplete. In this case it does \e not completely specify
the socket interface, it leaves some aspects open by assigning the Unspecified value to one or
more of the policy axis. A senf::SocketHandle based on such a policy will have a reduced
- interface: It will only support those members for wich the corresponding policies are defined.
+ interface: It will only support those members for which the corresponding policies are defined.
To build a senf::SocketPolicy instance the senf::MakeSocketPolicy helper is provided. This
helper template takes any number (it is really limited to 6 Arguments but more arguments don't
@@ -127,7 +127,7 @@
\section policy_group_details The Policy Framework Classes
In the following discussion, deeper insight into C++ and especially the concepts of template
- meta-programming are needed. Hoewever, this information is only needed if you want to write new
+ meta-programming are needed. However, this information is only needed if you want to write new
policy classes or want to use the policy framework explicitly for your own involved
optimizations ... or if you are just plain curious :-)
@@ -162,7 +162,7 @@
<dl><dt>\c class \c SocketPolicyBase</dt> <dd>This class is the base class of the SocketPolicy
template. It is used to validate, that a class is really a SocketPolicy (by checking, that it
- derives from SocketPolicyBase. This is simpler than chacking the template directly).</dd>
+ derives from SocketPolicyBase. This is simpler than checking the template directly).</dd>
<dt>\c template \c SocketPolicy < \e addressingPolicy, \e framingPolicy, \e communicationPolicy,
\e readPolicy, \e writePolicy, \e bufferingPolicy ></dt> <dd>This is the central SocketPolicy
@@ -176,18 +176,18 @@
arbitrary SocketPolicy. It will provide default values for unspecified axis</dd>
<dt>\c template \c SocketPolicyIsBaseOf < \e base, \e derived ></dt> <dd>This template
- metafunction will check, wether the socket policy \e derived is convertible to \e base. This
+ metafunction will check, whether the socket policy \e derived is convertible to \e base. This
means, that for each axis, the corresponding policy class in \e derived must be derived or be
the same as the one on \e base.</dd> </dl>
- \implementation All these classes are created automatically. The \c SENF_SOCKET_POLICIES makro
+ \implementation All these classes are created automatically. The \c SENF_SOCKET_POLICIES macro
is a Boost.Preprocessor style sequence listing all policy axis. The Boost.Preprocessor library
is then used to generate the respective classes.
\section policy_implement Implementing Policy Classes
To define a new policy class, derive from the corresponding base class for your policy
- axies. The only policy axis which might possibly need to be extended are the addressing policy
+ axes. The only policy axis which might possibly need to be extended are the addressing policy
(AddressingPolicyBase) and the buffering policy (BufferingPolicyBase). See the Documentation of
these classes for more information on which members can be implemented.
@@ -227,7 +227,7 @@
\idea We could combine all the \e Axis \c Is templates into a single template. Since the \e
trait argument will automatically specify the axis to be used, it is not necessary to specify
- that axis in the tempalte functor's name. We could even combine this with \c
+ that axis in the template functor's name. We could even combine this with \c
SocketPolicyIsBaseOf.
*/
@@ -306,7 +306,7 @@ namespace senf {
This policy does not define any operations since it does have no influence on any method
signature. It does however affect the semantics of the \c read() and \c write() operations.
- \note This policy axis probably only has two sensible statess: StreamFramingPolicy and
+ \note This policy axis probably only has two sensible states: StreamFramingPolicy and
DatagramFramingPolicy.
\see policy_group
@@ -344,7 +344,7 @@ namespace senf {
/** \brief Policy defining the readability
- The ReadPolicy defines, wether the socket is readable. It may define two members:
+ The ReadPolicy defines, whether the socket is readable. It may define two members:
<table class="senf">
<tr><td>method</td> <td><tt>unsigned read(FileHandle, char * buffer, unsigned size)</tt></td> <td>read data from socket</td></tr>
@@ -367,7 +367,7 @@ namespace senf {
/** \brief Policy defining the writability
- The WritePolicy defines, wether the socket is writable. It may define two members:
+ The WritePolicy defines, whether the socket is writable. It may define two members:
<table class="senf">
<tr><td>method</td> <td><tt>unsigned write(FileHandle, char * buffer, unsigned size)</tt></td> <td>read data from socket</td></tr>
@@ -390,7 +390,7 @@ namespace senf {
/** \brief Policy defining the buffering interface
- The BufferingPolicy defines the buffer handling of the socket. It may provide the follogin
+ The BufferingPolicy defines the buffer handling of the socket. It may provide the following
members:
\see policy_group
@@ -427,8 +427,8 @@ namespace senf {
/** \brief Check single policy axis
- This template is an example of the \e Axis \c Is family of tempalte metafunctions. It will
- check, wether \c Trait is a valid compatible Policy class of \c SocketPolicy. \c Trait must
+ This template is an example of the \e Axis \c Is family of template metafunctions. It will
+ check, whether \c Trait is a valid compatible Policy class of \c SocketPolicy. \c Trait must
be derived from AddressingPolicyBase (respectively \i Policy \c Base).
\see \ref policy_group
@@ -439,7 +439,7 @@ namespace senf {
/** \brief Enable template overload depending on policy value
- This template is an exmaple of the \c If \e Axis \c Is family of templates. It is used like
+ This template is an example of the \c If \e Axis \c Is family of templates. It is used like
<a href="http://www.boost.org/libs/utility/enable_if.html">Boost.enable_if</a> to enable a
templated overload only, if the AddressingPolicy of \e Axis is compatible with \c Trait
(that is the AddressingPolicy of \c Policy is derived from \c Trait).
@@ -472,7 +472,7 @@ namespace senf {
/** \brief Polymorphic access to policy axes
This is an example of a policy axes accessor. It returns a reference to the policy axes
- used by the conrecte protocol bundle. This reference can then be checked using RTTI
+ used by the concrete protocol bundle. This reference can then be checked using RTTI
information.
*/
AddressingPolicyBase const & theAddressingPolicy() const = 0;
@@ -498,7 +498,7 @@ namespace senf {
/** \brief Check dynamic policy compatibility
This method will check the socket policy \a other against this policy. It will check,
- wether \a other is a base policy (or the same) of this policy. This check is done
+ whether \a other is a base policy (or the same) of this policy. This check is done
against the \e dynamic type of \a other using RTTI. It will throw \c std::bad_cast, if
the policy is not compatible.
@@ -523,7 +523,7 @@ namespace senf {
/** \brief Check policy compatibility
- This tempalte metafunction checks, wether the SocketPolicy \c Derived is more specialized
+ This template metafunction checks, whether the SocketPolicy \c Derived is more specialized
than \c Base (and therefore a SocketHandle with policy \c Derived is convertible to a
SocketHandle with policy \c Base).
diff --git a/Socket/SocketProtocol.hh b/Socket/SocketProtocol.hh
index e4f9f211b..25316deca 100644
--- a/Socket/SocketProtocol.hh
+++ b/Socket/SocketProtocol.hh
@@ -29,7 +29,7 @@
the number of heap-allocations per socket to one which is good.
*/
-// The private inheritance idea should indeed work very well: We just need to chnage the
+// The private inheritance idea should indeed work very well: We just need to change the
// implementations of body() and protocol() and that of the ProtocolClient/ServerSocketHandle
// constructors and the SocketBody constructor. The body and the protocol would still be visible
// like several instances because of the private inheritance but we would save the backwards
@@ -152,7 +152,7 @@ namespace senf {
///< Return number of bytes available for reading without
///< blocking
/**< This member will check in a (very, sigh) protocol
- deqpendent way, how many bytes are guarateed to be
+ dependent way, how many bytes are guaranteed to be
readable from the socket without blocking even if the
socket is blocking. */
@@ -218,7 +218,7 @@ namespace senf {
SocketPolicy must be set to the complete socket policy of the protocol.
A protocol implementation may define the protocol interface directly. It can also
- (additnally) make use of multiple inheritance to combine a set of protocol facets into a
+ (additionally) make use of multiple inheritance to combine a set of protocol facets into a
specific protocol implementation (i.e. TCPv4SocketProtocol inherits from
ConcreteSocketProtocol and from the protocol facets IPv4Protocol, TCPProtocol,
BSDSocketProtocol and AddressableBSDSocketProtocol). The protocol facets are not concrete
diff --git a/Utils/DaemonTools.hh b/Utils/DaemonTools.hh
index a103c8664..cb335560e 100644
--- a/Utils/DaemonTools.hh
+++ b/Utils/DaemonTools.hh
@@ -26,11 +26,11 @@
\idea Add communication between parent and child process to daemonize() and add things like
init_done(), failure() etc which allow the daemon process to tell the frontend of successful
- startup or failure. This proabably means moving all the methods into a DaemonTools class (as
+ startup or failure. This probably means moving all the methods into a DaemonTools class (as
statics or via a singleton). This would also allow for automatic pid file creation and
removal (remove in global destructor).
- \idea Add a DaemonProcess baseclass whith init() and main() abstract members which wraps the
+ \idea Add a DaemonProcess baseclass with init() and main() abstract members which wraps the
startup process. DaeminProcess::run() would fork, call init(), create a pid file and then
call main(). Exceptions during init()'s execution would be passed to the parent
process. This is based on the above API.
diff --git a/Utils/Exception.hh b/Utils/Exception.hh
index 67435ba5f..212a6fb8e 100644
--- a/Utils/Exception.hh
+++ b/Utils/Exception.hh
@@ -37,7 +37,7 @@ namespace senf {
/** \brief Exception handling standard UNIX errors (errno)
- This exception is thrown to signal generic errno failuers.
+ This exception is thrown to signal generic errno failures.
\todo make where and err accessors and make the member vars private
@@ -49,13 +49,13 @@ namespace senf {
string and errno value as an argument and will throw a
corresponding template class instance. This would just be a
big switch statement containing all possible errno values,
- probably created using some makro metaprogramming.
+ probably created using some macro metaprogramming.
*/
class SystemException : public std::exception
{
public:
explicit SystemException(int err); ///< SystemException without error lokus info
- /**< \param[in] err errror number (the errno value) */
+ /**< \param[in] err error number (the errno value) */
SystemException(char const * where, int err); ///< SystemException with error lokus info
/**< \param[in] where description of error origin
\param[in] err error number (the errno value) */
diff --git a/Utils/Logger.hh b/Utils/Logger.hh
index b5d94a2cb..492dc0a0b 100644
--- a/Utils/Logger.hh
+++ b/Utils/Logger.hh
@@ -23,11 +23,11 @@
/** \defgroup logger The SENF Logger
- The Loggger infrastructure shall implement a highliy flexible compile- and run-time configurable
- logging infrastructure supporting multiple streams, user defineable log areas and fine grained
+ The Loggger infrastructure shall implement a highly flexible compile- and run-time configurable
+ logging infrastructure supporting multiple streams, user definable log areas and fine grained
log levels. Logging can be configured at compile and runtime on any combination of above
parameters. The library supports a host of log targets and messages can be routed into multiple
- targets at the same time. To allow concise usage of the libarary, a utlity to define logging
+ targets at the same time. To allow concise usage of the library, a utility to define logging
defaults for any scope is provided.
An important basic concept of the library is, that most of the macros take a variable number of
@@ -87,7 +87,7 @@
\endcode
Currently, the library is not implemented in any way. The interface has been defined up to a
- point and we have dummy implementations of the 'in-code' part ot the interface. This is the
+ point and we have dummy implementations of the 'in-code' part of the interface. This is the
part, which is called throughout the code. The configuration API is defined but we don't even
have a template implementation. However, this allows starting to use the SENF Logger in newly
developed code. Even though this code will unconditionally log everything to \c std::cerr for
diff --git a/Utils/MicroTime.hh b/Utils/MicroTime.hh
index 4c15b2489..6dd57efec 100644
--- a/Utils/MicroTime.hh
+++ b/Utils/MicroTime.hh
@@ -26,7 +26,7 @@
type precise to 10<sup>-6</sup> seconds. Up to now, the only
supported members are the datatype (which just uses a 64 bit
integer) and the now() function to get the current UTC time in
- microsecods since the Epoch.
+ microseconds since the Epoch.
\idea This thing only exists as a quick hack. We can probably make
use of Boost.Time or some such thing so it probably does not
diff --git a/Utils/SafeBool.hh b/Utils/SafeBool.hh
index 0b944bcf9..c0b7163f0 100644
--- a/Utils/SafeBool.hh
+++ b/Utils/SafeBool.hh
@@ -44,7 +44,7 @@ namespace senf {
better in this respect but still allows two instances of any
class having such a <tt>void *</tt> conversion to be compared
for equality. This again will produce absolutely unexpected
- results since it will not check wethere the objects are
+ results since it will not check whether the objects are
identical, it will only check, that both return the same
boolean state.
diff --git a/Utils/intrusive_refcount.hh b/Utils/intrusive_refcount.hh
index fe0f10e82..a0c36e0ff 100644
--- a/Utils/intrusive_refcount.hh
+++ b/Utils/intrusive_refcount.hh
@@ -41,7 +41,7 @@ namespace senf {
required interface. To make a class compatible with \c boost::intrusive_ptr, just derive
publicly from intrusive_refcount.
- Two additional benifits of using intrusive_refcount are
+ Two additional benefits of using intrusive_refcount are
\li The object can access it's own refcount
\li It is valid and safe to convert a plain object pointer to an intrusive_ptr at any time
(not only after new)
diff --git a/Utils/membind.hh b/Utils/membind.hh
index fdb56f4f2..62f68c137 100644
--- a/Utils/membind.hh
+++ b/Utils/membind.hh
@@ -41,7 +41,7 @@
\idea Make the \a ob argument type an additional P template
parameter (using call_traits for the exact arg type? Probably
we'll get deduction problems then) . The only operation this
- object musst suppoprt is ob->*fn. This would allow the use of
+ object must support is ob->*fn. This would allow the use of
smart pointers. We should keep the T & version to still support
ob.*fn use.
*/
diff --git a/senfscons/Mainpage.dox b/senfscons/Mainpage.dox
index bcdeb2764..847b2ff70 100644
--- a/senfscons/Mainpage.dox
+++ b/senfscons/Mainpage.dox
@@ -58,7 +58,7 @@ namespace senfscons {
<dt><tt>scons all_docs</tt></dt><dd>Build documentation of all modules</dd>
<dt><tt>scons all</tt></dt><dd>Build all targets including binaries, libraries, documentation,
- tests andpossible further targets </dd>
+ tests and possible further targets </dd>
<dt><tt>scons -u doc</tt></dt><dd>Run from within a module directory will build the
documentation of that module</dd>
@@ -106,7 +106,7 @@ namespace senfscons {
and have a prefix of \c Use. See \ref use.
After all frameworks are configured, you can use SEFNScons.MakeEnvironment() to create a
- corretly configured construction environment.
+ correctly configured construction environment.
To <i>configure the construction environment</i> you can set Variables in the construction
environment. See the SCons manpage for a list of supported variables. Some additional variables
--
GitLab