Spelling fixes to progdoc.

conf/cf-lex.l

@@ -7,9 +7,9 @@
  */
 
 /**
- * DOC: Lexical analyser
+ * DOC: Lexical analyzer
  *
- * The lexical analyser used for configuration files and CLI commands
+ * The lexical analyzer used for configuration files and CLI commands
  * is generated using the |flex| tool accompanied with a couple of
  * functions maintaining the hash tables containing information about
  * symbols and keywords.
@@ -341,7 +341,7 @@ cf_lex_init_kh(void)
  * cf_lex_init - initialize the lexer
  * @is_cli: true if we're going to parse CLI command, false for configuration
  *
- * cf_lex_init() initializes the lexical analyser and prepares it for
+ * cf_lex_init() initializes the lexical analyzer and prepares it for
  * parsing of a new input.
  */
 void
@@ -448,7 +448,7 @@ cf_symbol_class_name(struct symbol *sym)
 /**
  * DOC: Parser
  *
- * Both the configuration and CLI commands are analysed using a syntax
+ * Both the configuration and CLI commands are analyzed using a syntax
  * driven parser generated by the |bison| tool from a grammar which
  * is constructed from information gathered from grammar snippets by
  * the |gen_parser.m4| script.
@@ -460,7 +460,7 @@ cf_symbol_class_name(struct symbol *sym)
  * a list of |#include| directives needed by the C code, |CF_DEFINES|
  * for a list of C declarations, |CF_DECLS| for |bison| declarations
  * including keyword definitions specified as |CF_KEYWORDS|, |CF_GRAMMAR|
- * for the grammar rules, |CF_CODE| for auxillary C code and finally
+ * for the grammar rules, |CF_CODE| for auxiliary C code and finally
  * |CF_END| at the end of the snippet.
  *
  * To create references between the snippets, it's possible to define
@@ -468,7 +468,7 @@ cf_symbol_class_name(struct symbol *sym)
  * alternative to a multi-part rule.
  *
  * CLI commands are defined using a |CF_CLI| macro. Its parameters are:
- * the list of keywords determining the command, the list of paramaters,
+ * the list of keywords determining the command, the list of parameters,
  * help text for the parameters and help text for the command.
  *
  * Values of |enum| filter types can be defined using |CF_ENUM| with

conf/conf.c

@@ -12,7 +12,7 @@
  * Configuration of BIRD is complex, but straightforward. There exist three
  * modules taking care of the configuration: config manager (which takes care
  * of storage of config information and controls switching between configs),
- * lexical analyser and parser.
+ * lexical analyzer and parser.
  *
  * The configuration manager stores each config as a &config structure
  * accompanied by a linear pool from which all information associated
@@ -32,7 +32,7 @@
  * config by calling config_commit().
  *
  * CLI commands are parsed in a very similar way -- there is also a stripped-down
- * &config structure associated with them and they are lexed and parsed by the
+ * &config structure associated with them and they are lex-ed and parsed by the
  * same functions, only a special fake token is prepended before the command
  * text to make the parser recognize only the rules corresponding to CLI commands.
  */
@@ -91,10 +91,10 @@ config_alloc(byte *name)
  * config_parse() reads input by calling a hook function pointed to
  * by @cf_read_hook and parses it according to the configuration
  * grammar. It also calls all the preconfig and postconfig hooks
- * before resp. after parsing.
+ * before, resp. after parsing.
  *
  * Result: 1 if the config has been parsed successfully, 0 if any
- * error has occured (such as anybody calling cf_error()) and
+ * error has occurred (such as anybody calling cf_error()) and
  * the @err_msg field has been set to the error message.
  */
 int

filter/filter.c

@@ -20,7 +20,7 @@
  * Filter consists of tree of &f_inst structures, one structure per
  * "instruction". Each &f_inst contains code, aux value which is
  * usually type of data this instruction operates on, and two generic
- * arguments (a1, a2). Some instructinos contain pointer(s) to other
+ * arguments (a1, a2). Some instructions contain pointer(s) to other
  * instructions in their (a1, a2) fields.
  *
  * Filters use structure &f_val for its variables. Each &f_val
@@ -256,7 +256,7 @@ rta_cow(void)
 
 /**
  * interpret
- * @what: filter to interrpret
+ * @what: filter to interpret
  *
  * Interpret given tree of filter instructions. This is core function
  * of filter system and does all the hard work.
@@ -767,7 +767,7 @@ i_same(struct f_inst *f1, struct f_inst *f2)
  * f_run - external entry point to filters
  * @filter: pointer to filter to run
  * @tmp_attrs: where to store newly generated temporary attributes
- * @rte: pointer to pointer to rte being filtered. When route is modified, this is changed with rte_cow.
+ * @rte: pointer to pointer to &rte being filtered. When route is modified, this is changed with rte_cow().
  * @tmp_pool: all filter allocations go from this pool
  * @flags: flags
  */

lib/checksum.c

@@ -118,7 +118,7 @@ ipsum_verify(void *frag, unsigned len, ...)
  * @frag: first packet fragment
  * @len: length in bytes
  *
- * This function caculates a one's complement checksum of a given fragmented
+ * This function calculates a one's complement checksum of a given fragmented
  * packet.
  *
  * It uses all the clever tricks described in RFC 1071 to speed

lib/ip.c

@@ -19,7 +19,7 @@
  */
 
 /**
- * ip_scope_text - get texual representation of address scope
+ * ip_scope_text - get textual representation of address scope
  * @scope: scope (%SCOPE_xxx)
  *
  * Returns a pointer to a textual name of the scope given.
@@ -145,7 +145,7 @@ void ipa_ntoh(ip_addr x) { DUMMY }
  *
  * ipa_classify() returns an address class of @x, that is a bitwise or
  * of address type (%IADDR_INVALID, %IADDR_HOST, %IADDR_BROADCAST, %IADDR_MULTICAST)
- * with adress scope (%SCOPE_HOST to %SCOPE_UNIVERSE) or -1 (%IADDR_INVALID)
+ * with address scope (%SCOPE_HOST to %SCOPE_UNIVERSE) or -1 (%IADDR_INVALID)
  * for an invalid address.
  */
 int ipa_classify(ip_addr x) { DUMMY }
@@ -254,7 +254,7 @@ char *ip_ntox(ip_addr a, char *buf) { DUMMY }
  *
  * This function parses a textual IP address representation and
  * stores the decoded address to a variable pointed to by @o.
- * Returns 0 if a parse error has occured, else 0.
+ * Returns 0 if a parse error has occurred, else 0.
  */
 int ip_pton(char *a, ip_addr *o) { DUMMY }
 

lib/xmalloc.c

@@ -21,7 +21,7 @@
  * failure it calls die() to quit the program instead of returning
  * a %NULL pointer.
  *
- * Whereever possible, please use the memory resources instead.
+ * Wherever possible, please use the memory resources instead.
  */
 void *
 xmalloc(unsigned size)

nest/cli.c

@@ -36,7 +36,7 @@
  *
  * The CLI commands are declared as a part of the configuration grammar
  * by using the |CF_CLI| macro. When a command is received, it's processed
- * by the same lexical analyser and parser as used for the configuration, but
+ * by the same lexical analyzer and parser as used for the configuration, but
  * it's switched to a special mode by prepending a fake token to the text,
  * so that it uses only the CLI command rules. Then the parser invokes
  * an execution routine corresponding to the command, which either constructs

nest/proto-hooks.c

@@ -212,7 +212,7 @@ void neigh_notify(neighbor *neigh)
  * to convert the protocol attributes embedded directly in the &rte
  * to temporary extended attributes in order to distribute them
  * to other protocols or to filters. make_tmp_attrs() creates
- * an &ea_list in the linpool @pool, fills it with values of the
+ * an &ea_list in the linear pool @pool, fills it with values of the
  * temporary attributes and returns a pointer to it.
  */
 ea_list *make_tmp_attrs(rte *e, struct linpool *pool)

nest/proto.c

@@ -93,7 +93,7 @@ proto_relink(struct proto *p)
  * with data specific to the protocol)
  *
  * When a new configuration has been read in, the core code starts
- * initializing all the protocol instandces configured by calling their
+ * initializing all the protocol instances configured by calling their
  * init() hooks with the corresponding instance configuration. The initialization
  * code of the protocol is expected to create a new instance according to the
  * configuration by calling this function and then modifying the default settings
@@ -456,7 +456,7 @@ protos_dump_all(void)
  *
  * After the platform specific initialization code uses protos_build()
  * to add all the standard protocols, it should call proto_build() for
- * all platform specific protocols to infrom the core that they exist.
+ * all platform specific protocols to inform the core that they exist.
  */
 void
 proto_build(struct protocol *p)

nest/rt-attr.c

@@ -21,7 +21,7 @@
  * dynamic attributes represented by a linked list of &ea_list
  * structures, each of them consisting of an array of &eattr's containing
  * the individual attributes. An attribute can be specified more than once
- * in the &ea_list chain and in such case the first occurence overrides
+ * in the &ea_list chain and in such case the first occurrence overrides
  * the others. This semantics is used especially when someone (for example
  * a filter) wishes to alter values of several dynamic attributes, but
  * it wants to preserve the original attribute lists maintained by
@@ -33,7 +33,7 @@
  * embedded 32-bit value or a pointer to a &adata structure holding attribute
  * contents.
  *
- * There exist two variants of &rta's -- cached and uncached ones. Uncached
+ * There exist two variants of &rta's -- cached and un-cached ones. Un-cached
  * &rta's can have arbitrarily complex structure of &ea_list's and they
  * can be modified by any module in the route processing chain. Cached
  * &rta's have their attribute lists normalized (that means at most one
@@ -103,7 +103,7 @@ ea__find(ea_list *e, unsigned id)
  * @id: attribute ID to search for
  *
  * Given an extended attribute list, ea_find() searches for a first
- * occurence of an attribute with specified ID, returning either a pointer
+ * occurrence of an attribute with specified ID, returning either a pointer
  * to its &eattr structure or %NULL if no such attribute exists.
  */
 eattr *
@@ -214,7 +214,7 @@ ea_do_prune(ea_list *e)
  * within each of its entries.
  *
  * If an attribute occurs multiple times in a single &ea_list,
- * ea_sort() leaves only the first (the only significant) occurence.
+ * ea_sort() leaves only the first (the only significant) occurrence.
  */
 void
 ea_sort(ea_list *e)
@@ -637,9 +637,9 @@ rta_rehash(void)
 
 /**
  * rta_lookup - look up a &rta in attribute cache
- * @o: a uncached &rta
+ * @o: a un-cached &rta
  *
- * rta_lookup() gets an uncached &rta structure and returns its cached
+ * rta_lookup() gets an un-cached &rta structure and returns its cached
  * counterpart. It starts with examining the attribute cache to see whether
  * there exists a matching entry. If such an entry exists, it's returned and
  * its use count is incremented, else a new entry is created with use count

nest/rt-dev.c

@@ -9,7 +9,7 @@
 /**
  * DOC: Direct
  *
- * The Direct protocol works by convering all ifa_notify() events it receives
+ * The Direct protocol works by converting all ifa_notify() events it receives
  * to rte_update() calls for the corresponding network.
  */
 

nest/rt-table.c

@@ -80,7 +80,7 @@ rte_find(net *net, struct proto *p)
 /**
  * rte_get_temp - get a temporary &rte
  * @a: attributes to assign to the new route (a &rta; in case it's
- * uncached, rte_update() will create a cached copy automatically)
+ * un-cached, rte_update() will create a cached copy automatically)
  *
  * Create a temporary &rte and bind it with the attributes @a.
  * Also set route preference to the default preference set for
@@ -447,7 +447,7 @@ rte_update_unlock(void)
  *
  * This function is called by the routing protocols whenever they discover
  * a new route or wish to update/remove an existing route. The right announcement
- * sequence is to build route attributes first (either uncached with @aflags set
+ * sequence is to build route attributes first (either un-cached with @aflags set
  * to zero or a cached one using rta_lookup(); in this case please note that
  * you need to increase the use count of the attributes yourself by calling
  * rta_clone()), call rte_get_temp() to obtain a temporary &rte, fill in all
@@ -1125,7 +1125,7 @@ static inline net *net_get(rtable *tab, ip_addr addr, unsigned len)
  * shared with anyone else (and especially that it isn't stored in any routing
  * table).
  *
- * Result: a pointer to the new writeable &rte.
+ * Result: a pointer to the new writable &rte.
  */
 static inline rte * rte_cow(rte *r)
 { DUMMY; }

proto/bgp/bgp.c

@@ -566,12 +566,12 @@ bgp_init(struct proto_config *C)
  * bgp_error - report a protocol error
  * @c: connection
  * @code: error code (according to the RFC)
- * @subcode: error subcode
+ * @subcode: error sub-code
  * @data: data to be passed in the Notification message
  * @len: length of the data
  *
  * bgp_error() sends a notification packet to tell the other side that a protocol
- * error has occured (including the data considered erroneous if possible) and
+ * error has occurred (including the data considered erroneous if possible) and
  * closes the connection.
  */
 void

proto/rip/rip.c

@@ -21,8 +21,8 @@
  * DOC: Routing information protocol
  *
  * Rip is pretty simple protocol so half of this code is interface
- * with core. We maintain our own linklist of &rip_entry - it serves
+ * with core. We maintain our own linked list of &rip_entry -- it serves
- * as our small routing table. Rip never adds into this linklist at
+ * as our small routing table. Rip never adds into this linked list at
  * packet reception; instead, it lets core know about data from packet,
  * and waits for core to call our rip_rte_notify.
  *
@@ -30,7 +30,7 @@
  * walked, and packet is generated using rip_tx_prepare(). This gets
  * tricky because we may need to send more than one packet to one
  * destination. Struct &rip_connection is used to hold info such as how
- * many of &rip_entry ies we already send, and is also used to protect
+ * many of &rip_entry's we already send, and is also used to protect
  * from two concurrent sends to one destination. Each &rip_interface has
  * at most one &rip_connection.
  *
@@ -483,8 +483,8 @@ rip_dump_entry( struct rip_entry *e )
  *
  * Broadcast routing tables periodically (using rip_tx) and kill
  * routes that are too old. Rip keeps its own entries in main routing
- * table linked by link list (functions rip_rte_insert and
+ * table linked by link list (functions rip_rte_insert() and
- * rip_rte_delete are responsible for that), walks this list in timer
+ * rip_rte_delete() are responsible for that), walks this list in timer
  * and in case entry is too old, it is discarded.
  */
 
@@ -900,7 +900,7 @@ rip_rte_better(struct rte *new, struct rte *old)
 
 /*
  * rip_rte_insert - we maintain linked list of "our" entries in main
- * routing table, so that we can timeout them correctly. rip_timer
+ * routing table, so that we can timeout them correctly. rip_timer()
  * walks the list.
  */
 static void

sysdep/sysdep.sgml

@@ -16,7 +16,7 @@ code is isolated in a small set of modules:
 <descrip>
 <tagp><tt/config.h/</tagp> is a header file with configuration information,
 definition of the standard set of types and so on.
-<tagp/Startup module/ controls BIRD startup. Common for a family of OS'es (e.g.,
+<tagp/Startup module/ controls BIRD startup. Common for a family of OS's (e.g.,
 for all Unices).
 <tagp/Logging module/ manages the system logs. [per OS family]
 <tagp/IO module/ gives an implementation of sockets, timers and the

sysdep/unix/io.c

@@ -888,7 +888,7 @@ sk_send(sock *s, unsigned len)
  * @addr: IP address to send the packet to
  * @port: port to send the packet to
  *
- * This is a sk_send() replacement for connectionless packet sockets
+ * This is a sk_send() replacement for connection-less packet sockets
  * which allows destination of the packet to be chosen dynamically.
  */
 int

sysdep/unix/krt.c

@@ -16,14 +16,14 @@
  * The whole kernel synchronization is a bit messy and touches some internals
  * of the routing table engine, because routing table maintenance is a typical
  * example of the proverbial compatibility between different Unices and we want
- * to keep the overhead of our krt business as low as possible and avoid maintaining
+ * to keep the overhead of our KRT business as low as possible and avoid maintaining
  * a local routing table copy.
  *
  * The kernel syncer can work in three different modes (according to system config header):
  * Either with a single routing table and single KRT protocol [traditional Unix]
- * or with many routing tables and separate krt protocols for all of them
+ * or with many routing tables and separate KRT protocols for all of them
  * or with many routing tables, but every scan including all tables, so we start
- * separate krt protocols which cooperate with each other  [Linux 2.2].
+ * separate KRT protocols which cooperate with each other  [Linux 2.2].
  * In this case, we keep only a single scan timer.
  *
  * We use FIB node flags to keep track of route synchronization status. We also