chiark / gitweb /
Various fixes.
authormdw <mdw>
Wed, 23 Apr 2003 12:52:43 +0000 (12:52 +0000)
committermdw <mdw>
Wed, 23 Apr 2003 12:52:43 +0000 (12:52 +0000)
man/dstr.3
man/hash.3
man/lbuf.3
man/pkbuf.3
man/selpk.3

index b731715..70d7292 100644 (file)
@@ -172,17 +172,17 @@ buffer is allocated.
 .SS "Creation and destruction"
 The caller is responsible for allocating the
 .B dstr
-structure.  It can be initialized in any of the following ways:
+structure.  It can be initialized:
 .hP \*o
-Using the macro
+using the macro
 .B DSTR_INIT
-as an initializer in the declaration of the object.
+as an initializer in the declaration of the object,
 .hP \*o
-Passing its address to the
+passing its address to the
 .B dstr_create
-function.
+function, or
 .hP \*o
-Passing its address to the (equivalent)
+passing its address to the (equivalent)
 .B DCREATE
 macro.
 .PP
index f1cd782..d74edd4 100644 (file)
@@ -57,11 +57,11 @@ functions provide the basis for an extensible hashtable implementation.
 The implementation is not complete.  Many decisions have been left to
 the user, including:
 .hP \*o
-How keys should be represented, hashed and compared.
+how keys should be represented, hashed and compared;
 .hP \*o
-How objects contained within the table should be allocated.
+how objects contained within the table should be allocated; and
 .hP \*o
-When the hashtable should be extended.
+when the hashtable should be extended.
 .PP
 A complete hashtable implementation will need to take the above
 decisions.  If you just want a prepackaged solution, see
index b887130..29609fb 100644 (file)
@@ -207,10 +207,10 @@ the object so that it doesn't see any more data.
 .PP
 Clearly, since an
 .B lbuf_flush
-call can emit more than one line, so it must be aware that the line
-handler isn't interested in any more lines.  However, this fact must
-also be signalled to the higher-level object so that it can detach
-itself from its data source.
+call can emit more than one line, it must be aware that the line handler
+isn't interested in any more lines.  However, this fact must also be
+signalled to the higher-level object so that it can detach itself from
+its data source.
 .PP
 Rather than invent some complex interface for this, the line buffer
 exports one of its structure members,
index cdc6bac..4922b00 100644 (file)
@@ -78,7 +78,7 @@ This function is given three arguments: a pointer
 .I pk
 to a packet buffer structure; a pointer
 .I p
- to a chunk of data to read; and the size
+to a chunk of data to read; and the size
 .I sz
 of the chunk of data.  The data is pushed through the packet buffer and
 any complete packets are passed on to the packet handler.
@@ -128,7 +128,7 @@ each one in turn to the packet-handler function.
 The
 .B pkbuf_snarf
 function is trivially implemented in terms of the more complex
-.B pkbuf_free / pkbuf_flush
+.BR pkbuf_free / pkbuf_flush
 interface.
 .SS "Packet breaking and the handler function"
 The function
@@ -191,7 +191,7 @@ the object so that it doesn't see any more data.
 .PP
 Clearly, since an
 .B pkbuf_flush
-call can emit more than one packet, so it must be aware that the packet
+call can emit more than one packet, it must be aware that the packet
 handler isn't interested in any more packet.  However, this fact must
 also be signalled to the higher-level object so that it can detach
 itself from its data source.
index 665a883..6502803 100644 (file)
@@ -15,7 +15,7 @@ selpk \- packet-buffering input selector
 .BI "void selpk_disable(selpk *" pk );
 .BI "void selpk_want(selpk *" pk ", size_t " sz );
 .BI "void selpk_init(selpk *" pk ", sel_state *" s ", int " fd ,
-.BI "                pkbuf *" func ", void *" p );
+.BI "                pkbuf_func *" func ", void *" p );
 .BI "void selpk_destroy(selpk *" b );
 .fi
 .SH DESCRIPTION