--- libecb/ecb.pod	2011/05/27 00:01:28	1.18
+++ libecb/ecb.pod	2011/05/27 00:04:05	1.19
@@ -107,12 +107,12 @@
      abort ();
    }
 
-In this case, the compiler would probbaly be smart enough to decude it on
-it's own, so this is mainly useful for declarations.
+In this case, the compiler would probably be smart enough to deduce it on
+its own, so this is mainly useful for declarations.
 
 =item ecb_const
 
-Declares that the function only depends on the values of it's arguments,
+Declares that the function only depends on the values of its arguments,
 much like a mathematical function. It specifically does not read or write
 any memory any arguments might point to, global variables, or call any
 non-const functions. It also must not have any side effects.
@@ -123,7 +123,7 @@
 expect any side effects.
 
 It is best suited for functions in the sense of mathematical functions,
-such as a function return the square root of its input argument.
+such as a function returning the square root of its input argument.
 
 Not suited would be a function that calculates the hash of some memory
 area you pass in, prints some messages or looks at a global variable to
@@ -156,7 +156,7 @@
 The compiler reacts by trying to place hot functions near to each other in
 memory.
 
-Whether a function is hot or not often depend son the whole program,
+Whether a function is hot or not often depends on the whole program,
 and less on the function itself. C<ecb_cold> is likely more useful in
 practise.
 
@@ -171,7 +171,7 @@
 functions), this knowledge can be used in other ways, for example, the
 function will be optimised for size, as opposed to speed, and codepaths
 leading to calls to those functions can automatically be marked as if
-C<ecb_unlikel> had been used to reach them.
+C<ecb_unlikely> had been used to reach them.
 
 Good examples for such functions would be error reporting functions, or
 functions only called in exceptional or rare cases.