chiark / gitweb /
Version bump.
[mLib] / man / lbuf.3
1 .\" -*-nroff-*-
2 .TH lbuf 3 "6 July 1999" mLib
3 .SH "NAME"
4 lbuf \- split lines out of asynchronously received blocks
5 .\" @lbuf_flush
6 .\" @lbuf_close
7 .\" @lbuf_free
8 .\" @lbuf_snarf
9 .\" @lbuf_init
10 .SH "SYNOPSIS"
11 .nf
12 .B "#include <mLib/lbuf.h>"
13
14 .BI "void lbuf_flush(lbuf *" b ", char *" p ", size_t " len );
15 .BI "void lbuf_close(lbuf *" b );
16 .BI "size_t lbuf_free(lbuf *" b ", char **" p );
17 .BI "void lbuf_snarf(lbuf *" b ", const void *" p ", size_t " sz );
18 .BI "void lbuf_setsize(lbuf *" b ", size_t " sz );
19 .BI "void lbuf_init(lbuf *" b ,
20 .BI "               void (*" func ")(char *" s ", void *" p ),
21 .BI "               void *" p );
22 .BI "void lbuf_destroy(lbuf *" b );
23 .fi
24 .SH "DESCRIPTION"
25 The declarations in
26 .B <mLib/lbuf.h>
27 implement a handy object called a
28 .IR "line buffer" .
29 Given unpredictably-sized chunks of data, the line buffer extracts
30 completed lines of text and passes them to a caller-supplied function.
31 This is useful in nonblocking network servers, for example: the server
32 can feed input from a client into a line buffer as it arrives and deal
33 with completed text lines as they appear without having to wait for
34 newline characters.
35 .PP
36 The state of a line buffer is stored in an object of type
37 .BR lbuf .
38 This is a structure which must be allocated by the caller.  The
39 structure should normally be considered opaque (see the section on
40 .B Disablement
41 for an exception to this).
42 .SS "Initialization and finalization"
43 The function
44 .B lbuf_init
45 initializes a line buffer ready for use.  It is given three arguments:
46 .TP
47 .BI "lbuf *" b
48 A pointer to the block of memory to use for the line buffer.  This is
49 all the memory the line buffer requires.
50 .TP
51 .BI "void (*" func ")(char *" s ", void *" p )
52 The
53 .I line-handler
54 function to which the line buffer should pass completed lines of text.
55 .TP
56 .BI "void *" p
57 A pointer argument to be passed to the function when a completed line of
58 text arrives.
59 .PP
60 The amount of memory set aside for reading lines is configurable.  It
61 may be set by calling
62 .B lbuf_setsize
63 at any time when the buffer is empty.  The default limit is 256 bytes.
64 Lines longer than the limit are truncated.  By default, the buffer is
65 allocated from the current arena,
66 .BR arena_global (3);
67 this may be changed by altering the buffer's
68 .B a
69 member to refer to a different arena at any time when the buffer is
70 unallocated.
71 .PP
72 A line buffer must be destroyed after use by calling
73 .BR lbuf_destroy ,
74 passing it the address of the buffer block.
75 .SS "Inserting data into the buffer"
76 There are two interfaces for inserting data into the buffer.  One's much
77 simpler than the other, although it's less expressive.
78 .PP
79 The simple interface is
80 .BR lbuf_snarf .
81 This function is given three arguments: a pointer
82 .I b
83 to a line buffer structure; a pointer
84 .I p
85  to a chunk of data to read; and the size
86 .I sz
87 of the chunk of data.  The data is pushed through the line buffer and
88 any complete lines are passed on to the line handler.
89 .PP
90 The complex interface is the pair of functions
91 .I lbuf_free
92 and
93 .IR lbuf_flush .
94 .PP
95 The 
96 .B lbuf_free
97 function returns the address and size of a free portion of the line
98 buffer's memory into which data may be written.  The function is passed
99 the address 
100 .I l
101 of the line buffer.  Its result is the size of the free area, and it
102 writes the base address of this free space to the location pointed to by
103 the argument
104 .IR p .
105 The caller's data must be written to ascending memory locations starting
106 at
107 .BI * p
108 and no data may be written beyond the end of the free space.  However,
109 it isn't necessary to completely fill the buffer.
110 .PP
111 Once the free area has had some data written to it,
112 .B lbuf_flush
113 is called to examine the new data and break it into text lines.  This is
114 given three arguments:
115 .TP
116 .BI "lbuf *" b
117 The address of the line buffer.
118 .TP
119 .BI "char *" p
120 The address at which the new data has been written.  This must be the
121 base address returned from
122 .BR lbuf_free .
123 .TP
124 .BI "size_t " len
125 The number of bytes which have been written to the buffer.
126 .PP
127 The
128 .B lbuf_flush
129 function breaks the new data into lines as described below, and passes
130 each one in turn to the line-handler function.
131 .PP
132 The
133 .B lbuf_snarf
134 function is trivially implemented in terms of the more complex
135 .B lbuf_free / lbuf_flush
136 interface.
137 .SS "Line breaking"
138 The line buffer considers a line to end with either a simple linefeed
139 character (the normal Unix convention) or a carriage-return/linefeed
140 pair (the Internet convention).
141 .PP
142 The line buffer has a fixed amount of memory available to it.  This is
143 deliberate, to prevent a trivial attack whereby a remote user sends a
144 stream of data containing no newline markers, wasting the server's
145 memory.  Instead, the buffer will truncate overly long lines (silently)
146 and return only the initial portion.  It will ignore the rest of the
147 line completely.
148 .SS "Line-handler functions"
149 Completed lines, as already said, are passed to the caller's
150 line-handler function.  The function is given two arguments:
151 the address
152 .I s
153 of the line which has just been read, and the pointer
154 .I p
155 which was set up in the call to
156 .B lbuf_init .
157 The line passed is null-terminated, and has had its trailing newline
158 stripped.  The area of memory in which the string is located may be
159 overwritten by the line-handler function, although writing beyond the
160 terminating zero byte is not permitted.
161 .PP
162 The line pointer argument
163 .I s
164 may be null to signify end-of-file.  See the next section.
165 .SS "Flushing the remaining data"
166 When the client program knows that there's no more data arriving (for
167 example, an end-of-file condition exists on its data source) it should
168 call the function
169 .BR lbuf_close
170 to flush out the remaining data in the buffer as one last (improperly
171 terminated) line.  This will pass the remaining text to the line
172 handler, if there is any, and then call the handler one final time with
173 a null pointer rather than the address of a text line to inform it of
174 the end-of-file.
175 .SS "Disablement"
176 The line buffer is intended to be used in higher-level program objects,
177 such as the buffer selector described in
178 .BR selbuf (3).
179 Unfortunately, a concept from this high level needs to exist at the line
180 buffer level, which complicates the description somewhat.  The idea is
181 that, when a line-handler attached to some higher-level object decides
182 that it's read enough, it can
183 .I disable
184 the object so that it doesn't see any more data.
185 .PP
186 Clearly, since an
187 .B lbuf_flush
188 call can emit more than one line, so it must be aware that the line
189 handler isn't interested in any more lines.  However, this fact must
190 also be signalled to the higher-level object so that it can detach
191 itself from its data source.
192 .PP
193 Rather than invent some complex interface for this, the line buffer
194 exports one of its structure members,
195 .BR flags .
196 A higher-level object wishing to disable the line buffer simply clears
197 the bit
198 .B LBUF_ENABLE
199 in the flags word.
200 .PP
201 Disabling a buffer causes an immediate return from
202 .BR lbuf_flush .
203 However, it is not permitted for the functions
204 .B lbuf_flush
205 or
206 .B lbuf_close
207 to be called on a disabled buffer.  (This condition isn't checked for;
208 it'll just do the wrong thing.)  Furthermore, the
209 .B lbuf_snarf
210 function does not handle disablement at all, because it would complicate
211 the interface so much that it wouldn't have any advantage over the more
212 general
213 .BR lbuf_free / lbuf_flush .
214 .SH "SEE ALSO"
215 .BR selbuf (3),
216 .BR mLib (3).
217 .SH "AUTHOR"
218 Mark Wooding, <mdw@nsict.org>