From 87d99348a110a52fbc6e225b360e566fc474956a Mon Sep 17 00:00:00 2001
From: Brad Hards <bradh@frogmouth.net>
Date: Sun, 16 Jan 2011 17:50:03 +1100
Subject: [PATCH] tdb: spelling fixes

---
 ccan/tdb/freelist.c | 2 +-
 ccan/tdb/tdb.c      | 2 +-
 ccan/tdb/traverse.c | 4 ++--
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/ccan/tdb/freelist.c b/ccan/tdb/freelist.c
index 8113b549..c7d908ed 100644
--- a/ccan/tdb/freelist.c
+++ b/ccan/tdb/freelist.c
@@ -98,7 +98,7 @@ static int update_tailer(struct tdb_context *tdb, tdb_off_t offset,
 }
 
 /* Add an element into the freelist. Merge adjacent records if
-   neccessary. */
+   necessary. */
 int tdb_free(struct tdb_context *tdb, tdb_off_t offset, struct tdb_record *rec)
 {
 	/* Allocation and tailer lock */
diff --git a/ccan/tdb/tdb.c b/ccan/tdb/tdb.c
index ede00275..7317a3aa 100644
--- a/ccan/tdb/tdb.c
+++ b/ccan/tdb/tdb.c
@@ -213,7 +213,7 @@ TDB_DATA tdb_fetch(struct tdb_context *tdb, TDB_DATA key)
  * function. The parsing function is executed under the chain read lock, so it
  * should be fast and should not block on other syscalls.
  *
- * DONT CALL OTHER TDB CALLS FROM THE PARSER, THIS MIGHT LEAD TO SEGFAULTS.
+ * DON'T CALL OTHER TDB CALLS FROM THE PARSER, THIS MIGHT LEAD TO SEGFAULTS.
  *
  * For mmapped tdb's that do not have a transaction open it points the parsing
  * function directly at the mmap area, it avoids the malloc/memcpy in this
diff --git a/ccan/tdb/traverse.c b/ccan/tdb/traverse.c
index d329ef4d..c605c8e6 100644
--- a/ccan/tdb/traverse.c
+++ b/ccan/tdb/traverse.c
@@ -39,7 +39,7 @@ static tdb_off_t tdb_next_lock(struct tdb_context *tdb, struct tdb_traverse_lock
 	/* Lock each chain from the start one. */
 	for (; tlock->hash < tdb->header.hash_size; tlock->hash++) {
 		if (!tlock->off && tlock->hash != 0) {
-			/* this is an optimisation for the common case where
+			/* this is an optimization for the common case where
 			   the hash chain is empty, which is particularly
 			   common for the use of tdb with ldb, where large
 			   hashes are used. In that case we spend most of our
@@ -53,7 +53,7 @@ static tdb_off_t tdb_next_lock(struct tdb_context *tdb, struct tdb_traverse_lock
 			   lock, so instead we get the lock and re-fetch the
 			   value below.
 			   
-			   Notice that not doing this optimisation on the
+			   Notice that not doing this optimization on the
 			   first hash chain is critical. We must guarantee
 			   that we have done at least one fcntl lock at the
 			   start of a search to guarantee that memory is
-- 
2.39.2