chiark / gitweb /
Add lots of references to manual pages, and fix a typo.
[mLib] / man / mLib.3
CommitLineData
05fbeb03 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
484eed5d 9library is a mixed bag of things which the author finds useful in large
05fbeb03 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
484eed5d 26.BR .h> .
05fbeb03 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
484eed5d 37.BR exc (3)
05fbeb03 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
484eed5d 42.BR alloc (3)
05fbeb03 43module provides simple veneers onto traditional memory allocation
44functions like
45.BR malloc (3)
46and
47.BR strdup (3)
48(although
49.B mLib
50doesn't actually depend on
51.B strdup
52being defined in the library) which raise exceptions when there's not
53enough memory left.
54.PP
55The
484eed5d 56.BR sub (3)
05fbeb03 57module handles efficient allocation of small blocks. It allocates
58memory in relatively big chunks and divides the chunks up into small
59blocks before returning them. It keeps lists of differently-sized
60blocks so allocation and freeing is fast. The downside is that your
61code must know how big a block is when it's being freed.
62.PP
63The
64.B track
65module (not yet documented) is a simple memory allocation tracker. It
66can be handy when trying to fix memory leaks.
67.SS "String handling"
68The
484eed5d 69.BR str (3)
05fbeb03 70module provides some trivial string-manipulation functions which tend to
71be useful quite often.
72.PP
73The
484eed5d 74.BR dstr (3)
05fbeb03 75module implements a dynamic string data type. It works quite quickly
76and well, and is handy in security-sensitive programs, to prevent
77buffer-overflows. Dynamic strings are used occasionally through the
78rest of the library, mainly as output arguments.
79.PP
80The
484eed5d 81.BR dspool (3)
05fbeb03 82module implements a `pool' of dynamic strings which saves lots of
83allocation and deallocation when a piece of code has high string
84turnover.
85.SS "Program identification and error reporting"
86The
484eed5d 87.BR quis (3)
05fbeb03 88module remembers the name of the program and supplies it when asked.
89It's used in error messages and similar things.
90.PP
91The
484eed5d 92.BR report (3)
05fbeb03 93module emits standard Unixy error messages. It provides functions
94.B moan
95and
96.B die
97which the author uses rather a lot.
98.PP
99The
100.B trace
101module (not yet documented)
102provides an interface for emitting tracing information with configurable
103verbosity levels. It needs improving to be able to cope with outputting
104to the system log.
105.SS "Other data types"
106The
484eed5d 107.BR sym (3)
05fbeb03 108module implements a rather good extending hash table. Keys and values can
109be arbitrary data.
110.PP
111The
112.B dynarray
113module (not yet documented) implements unbounded sparse arrays. It
114needs rewriting.
115.SS "Miscellaneous utilities"
116The
484eed5d 117.BR crc32 (3)
05fbeb03 118module calculates CRC values for strings. It's used by the symbol table
119manager as a hash function.
120.PP
121The
484eed5d 122.BR lock (3)
05fbeb03 123module does POSIX
124.BR fcntl (2)-style
125locking with a timeout.
126.PP
127The
484eed5d 128.BR env (3)
3fecac47 129module manipulates environment variables stored in a hashtable, and
130converts between the hashtable and the standard array representation of
131a process environment.
132.PP
133The
484eed5d 134.BR fdflags (3)
3fecac47 135module manipulates file descriptor flags in a fairly painless way.
136.PP
137The
484eed5d 138.BR lbuf (3)
05fbeb03 139module implements a `line buffer', which is an object that emits
140completed lines of text from an incoming asynchronous data stream. It's
141remarkably handy in programs that want to read lines from pipes and
142sockets can't block while waiting for a line-end to arrive.
143.PP
144The
484eed5d 145.BR tv (3)
05fbeb03 146module provides some macros and functions for playing with
484eed5d 147.BR "struct timeval" .
05fbeb03 148.PP
149The
484eed5d 150.BR bits (3)
05fbeb03 151module defines some types and macros for playing with words as chunks of
152bits. There are portable rotate and shift macros (harder than you'd
153think), and macros to do loading and storing in known-endian formats.
154values.
155.PP
156The
484eed5d 157.BR mdwopt (3)
05fbeb03 158module implements a fairly serious options parser compatible with the
159GNU options parser.
160.PP
161The
484eed5d 162.BR testrig (3)
05fbeb03 163module provides a generic structure for reading test vectors from files
164and running them through functions. I mainly use it for testing
165cryptographic transformations of various kinds.
166.SS "Encoding and decoding"
167The
484eed5d 168.BR base64 (3)
05fbeb03 169module does base64 encoding and decoding, as defined in RFC2045. Base64
170encodes arbitrary binary data in a reliable way which is resistant to
171character-set transformations and other mail transport bogosity.
172.PP
173The
484eed5d 174.BR url (3)
05fbeb03 175module does urlencoding and decoding, as defined in RFC1866.
176Urlencoding encodes arbitrary (but mostly text-like) name/value pairs as
177a text string containing no whitespace.
178.SS "Multiplexed I/O"
179The
484eed5d 180.BR sel (3)
05fbeb03 181module provides a basis for doing nonblocking I/O in Unix systems. It
182provides types and functions for receiving events when files are ready
183for reading or writing, and when timers expire.
184.PP
185The
484eed5d 186.BR conn (3)
05fbeb03 187module implements nonblocking network connections in a way which fits in
188with the
189.B sel
190system. It makes nonblocking connects pretty much trivial.
191.PP
192The
484eed5d 193.BR selbuf (3)
05fbeb03 194module attaches to the
195.B sel
196system and sends an event when lines of text arrive on a file. It's
197useful when reading text from a network connection.
484eed5d 198.PP
199The
200.BR sig (3)
201module introduces signal handling into the multiplexed I/O world.
202Signals are queued until dispatched through the normal
203.B sel
204mechanism.
05fbeb03 205.SH "SEE ALSO"
206.BR alloc (3),
207.BR base64 (3),
208.BR bits (3),
209.BR conn (3),
210.BR crc32 (3),
211.BR dspool (3),
212.BR dstr (3),
3fecac47 213.BR env (3),
05fbeb03 214.BR exc (3),
3fecac47 215.BR fdflags (3),
05fbeb03 216.BR lbuf (3),
217.BR lock (3),
218.BR mdwopt (3),
219.BR quis (3),
220.BR report (3),
221.BR sel (3),
222.BR selbuf (3),
484eed5d 223.BR sig (3),
05fbeb03 224.BR str (3),
225.BR sub (3),
226.BR sym (3),
227.BR tv (3),
228.BR url (3).
229.SH AUTHOR
230Mark Wooding, <mdw@nsict.org>