|
Check-in Number:
|
2671 | |
| Date: |
2002-Oct-25 19:36:08 (local)
2002-Oct-25 17:36:08 (UTC) |
| User: | rse |
| Branch: | |
| Comment: |
fix typos |
| Tickets: |
|
| Inspections: |
|
| Files: |
|
ossp-pkg/sa/sa.pod 1.27 -> 1.28
--- sa.pod 2002/10/25 16:07:41 1.27
+++ sa.pod 2002/10/25 17:36:08 1.28
@@ -128,7 +128,7 @@
=item B<Address Abstraction>
-Most of the uglyness in the Unix I<Socket> API is the necessarity to
+Most of the ugliness in the Unix I<Socket> API is the necessity to
have to deal with the various address structures (C<struct sockaddr_xx>)
which exist because of both the different communication types and
addressing schemes. B<OSSP sa> fully hides this by providing an abstract
@@ -174,7 +174,7 @@
by sa_buffer()) for achieving higher I/O performance by doing I/O
operations on larger aggregated messages and with less required system
calls. Additionally if B<OSSP sa> is used for stream communication, for
-convinience reasons line-oriented reading (sa_readln()) and formatted
+convenience reasons line-oriented reading (sa_readln()) and formatted
writing (see sa_writef()) is provided, modelled after STDIO's fgets(3)
and fprintf(3). Both features fully leverage from the I/O buffering.
@@ -275,7 +275,7 @@
=item sa_rc_t B<sa_addr_s2a>(sa_addr_t *I<saa>, const struct sockaddr *I<sabuf>, socklen_t I<salen>);
-Import an address by converting from a tranditional C<struct sockaddr>
+Import an address by converting from a traditional C<struct sockaddr>
object to the corresponding address abstraction.
The accepted addresses for I<sabuf> are: C<struct sockaddr_un>
@@ -570,7 +570,7 @@
request on the queue of pending connections. It creates a new socket
abstraction object (returned in I<csa>) and a new socket address
abstraction object (returned in I<caddr>) describing the connection. The
-caller has to destroy these objects laters. If no pending connections
+caller has to destroy these objects later. If no pending connections
are present on the queue, it blocks the caller until a connection is
present.
|
|
