chiark / gitweb /
Insert missing `NAME' section. Use a pleasant `>=' sign when doing good
[mLib] / man / mLib.3
... / ...
CommitLineData
1.\" -*-nroff-*-
2.TH mLib 3 "7 July 1999" mLib
3.SH NAME
4mLib \- library of miscellaneous utilities
5.\" @mLib
6.SH DESCRIPTION
7The
8.B mLib
9library is a mixed bag of things which the author finds useful in large
10numbers of programs. As a result, its structure is somewhat arbitrary,
11and it's accreted extra bits over time rather than actually being
12designed as a whole. In the author's opinion this isn't too much of a
13hardship.
14.PP
15At the most granular level,
16.B mLib
17is split into `modules', each of which has its own header file and
18manual page. Sometimes there are identifiable `chunks' of several
19modules which fit together as a whole. Modules and chunks fit into
20`layers', each depending on the ones below it. The header file for
21module
22.I foo
23would be put in
24.BR <mLib/ \c
25.IR foo \c
26.BR .h> .
27.PP
28This description is a bit abstract, and
29.BR mLib ,
30as a result of its history, doesn't fit it as well as I might like.
31Even so, it's not too bad a model really.
32.PP
33The rest of this section describes the various chunks and layers.
34.SS "Exception handling"
35Right at the bottom, there's a fairly primitive exception handling
36system. It's provided by the
37.BR exc (3)
38module, and stands alone. It's used mainly by the memory allocation
39modules to raise exceptions when there's no more memory to be had.
40.SS "Memory allocation"
41The
42.BR arena (3)
43module provides an abstraction of memory allocation. By writing
44appropriate arena implementations, a client program can control where
45and how memory is allocated for various structures.
46.PP
47The
48.BR alloc (3)
49module provides simple veneers onto traditional memory allocation
50functions like
51.BR malloc (3)
52and
53.BR strdup (3)
54(although
55.B mLib
56doesn't actually depend on
57.B strdup
58being defined in the library) which raise exceptions when there's not
59enough memory left. These work through the
60.B arena
61layer, so that the caller can control memory allocation.
62.PP
63The
64.BR sub (3)
65module handles efficient allocation of small blocks. It allocates
66memory in relatively big chunks and divides the chunks up into small
67blocks before returning them. It keeps lists of differently-sized
68blocks so allocation and freeing is fast. The downside is that your
69code must know how big a block is when it's being freed.
70.PP
71The
72.B track
73module (not yet documented) is a simple memory allocation tracker. It
74can be handy when trying to fix memory leaks.
75.PP
76The
77.BR pool (3)
78module maintains resource pools which can manage memory and other
79resources, all of the resources held in a pool being destroyed along
80with the pool itself.
81.SS "String handling"
82The
83.BR str (3)
84module provides some trivial string-manipulation functions which tend to
85be useful quite often.
86.PP
87The
88.BR dstr (3)
89module implements a dynamic string data type. It works quite quickly
90and well, and is handy in security-sensitive programs, to prevent
91buffer-overflows. Dynamic strings are used occasionally through the
92rest of the library, mainly as output arguments.
93.PP
94The
95.BR dspool (3)
96module implements a `pool' of dynamic strings which saves lots of
97allocation and deallocation when a piece of code has high string
98turnover.
99.SS "Program identification and error reporting"
100The
101.BR quis (3)
102module remembers the name of the program and supplies it when asked.
103It's used in error messages and similar things.
104.PP
105The
106.BR report (3)
107module emits standard Unixy error messages. It provides functions
108.B moan
109and
110.B die
111which the author uses rather a lot.
112.PP
113The
114.BR trace (3)
115module provides an interface for emitting tracing information with
116configurable verbosity levels. It needs improving to be able to cope
117with outputting to the system log.
118.SS "Other data types"
119The
120.BR hash (3)
121module provides the basics for an extending hashtable implementation.
122Many different hashtable-based data structures can be constructed with
123little effort.
124.PP
125The
126.BR sym (3)
127module implements a rather good general-purpose extending hash table.
128Keys and values can be arbitrary data. It is implemented using
129.BR hash (3).
130.PP
131The
132.BR darray (3)
133module implements dynamically resizing arrays which support Perl-like
134stack operations efficiently.
135.SS "Miscellaneous utilities"
136The
137.BR crc32 (3)
138module calculates CRC values for strings. It's used by the symbol table
139manager as a hash function.
140.PP
141The
142.BR lock (3)
143module does POSIX
144.BR fcntl (2)-style
145locking with a timeout.
146.PP
147The
148.BR env (3)
149module manipulates environment variables stored in a hashtable, and
150converts between the hashtable and the standard array representation of
151a process environment.
152.PP
153The
154.BR fdflags (3)
155module manipulates file descriptor flags in a fairly painless way.
156.PP
157The
158.BR lbuf (3)
159module implements a `line buffer', which is an object that emits
160completed lines of text from an incoming asynchronous data stream. It's
161remarkably handy in programs that want to read lines from pipes and
162sockets can't block while waiting for a line-end to arrive.
163.PP
164The
165.BR tv (3)
166module provides some macros and functions for playing with
167.BR "struct timeval" .
168.PP
169The
170.BR bits (3)
171module defines some types and macros for playing with words as chunks of
172bits. There are portable rotate and shift macros (harder than you'd
173think), and macros to do loading and storing in known-endian formats.
174values.
175.PP
176The
177.BR mdwopt (3)
178module implements a fairly serious options parser compatible with the
179GNU options parser.
180.PP
181The
182.BR testrig (3)
183module provides a generic structure for reading test vectors from files
184and running them through functions. I mainly use it for testing
185cryptographic transformations of various kinds.
186.SS "Encoding and decoding"
187The
188.BR base64 (3)
189module does base64 encoding and decoding, as defined in RFC2045. Base64
190encodes arbitrary binary data in a reliable way which is resistant to
191character-set transformations and other mail transport bogosity.
192.PP
193The
194.BR url (3)
195module does urlencoding and decoding, as defined in RFC1866.
196Urlencoding encodes arbitrary (but mostly text-like) name/value pairs as
197a text string containing no whitespace.
198.SS "Multiplexed I/O"
199The
200.BR sel (3)
201module provides a basis for doing nonblocking I/O in Unix systems. It
202provides types and functions for receiving events when files are ready
203for reading or writing, and when timers expire.
204.PP
205The
206.BR conn (3)
207module implements nonblocking network connections in a way which fits in
208with the
209.B sel
210system. It makes nonblocking connects pretty much trivial.
211.PP
212The
213.BR selbuf (3)
214module attaches to the
215.B sel
216system and sends an event when lines of text arrive on a file. It's
217useful when reading text from a network connection.
218.PP
219The
220.BR sig (3)
221module introduces signal handling into the multiplexed I/O world.
222Signals are queued until dispatched through the normal
223.B sel
224mechanism.
225.PP
226The
227.BR ident (3)
228module provides a nonblocking ident (RFC931) client.
229.PP
230The
231.BR bres (3)
232module does background hostname and address resolution.
233.SH "SEE ALSO"
234.BR alloc (3),
235.BR base64 (3),
236.BR bits (3),
237.BR bres (3),
238.BR conn (3),
239.BR crc32 (3),
240.BR darray (3),
241.BR dspool (3),
242.BR dstr (3),
243.BR env (3),
244.BR exc (3),
245.BR fdflags (3),
246.BR hash (3),
247.BR ident (3),
248.BR lbuf (3),
249.BR lock (3),
250.BR mdwopt (3),
251.BR quis (3),
252.BR report (3),
253.BR sel (3),
254.BR selbuf (3),
255.BR sig (3),
256.BR str (3),
257.BR sub (3),
258.BR sym (3),
259.BR trace (3),
260.BR tv (3),
261.BR url (3).
262.SH AUTHOR
263Mark Wooding, <mdw@nsict.org>