chiark / gitweb /
Makefile for manual page installation. Subtle and complicated.
[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
9library is a mixed back 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 > .
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.B exc
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.B alloc
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
56.B sub
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
69.B str
70module provides some trivial string-manipulation functions which tend to
71be useful quite often.
72.PP
73The
74.B dstr
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
81.B dspool
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
87.B quis
88module remembers the name of the program and supplies it when asked.
89It's used in error messages and similar things.
90.PP
91The
92.B report
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
107.B sym
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
117.B crc32
118module calculates CRC values for strings. It's used by the symbol table
119manager as a hash function.
120.PP
121The
122.B lock
123module does POSIX
124.BR fcntl (2)-style
125locking with a timeout.
126.PP
127The
128.B lbuf
129module implements a `line buffer', which is an object that emits
130completed lines of text from an incoming asynchronous data stream. It's
131remarkably handy in programs that want to read lines from pipes and
132sockets can't block while waiting for a line-end to arrive.
133.PP
134The
135.B tv
136module provides some macros and functions for playing with
137.B "struct timeval"
138.PP
139The
140.B bits
141module defines some types and macros for playing with words as chunks of
142bits. There are portable rotate and shift macros (harder than you'd
143think), and macros to do loading and storing in known-endian formats.
144values.
145.PP
146The
147.B mdwopt
148module implements a fairly serious options parser compatible with the
149GNU options parser.
150.PP
151The
152.B testrig
153module provides a generic structure for reading test vectors from files
154and running them through functions. I mainly use it for testing
155cryptographic transformations of various kinds.
156.SS "Encoding and decoding"
157The
158.B base64
159module does base64 encoding and decoding, as defined in RFC2045. Base64
160encodes arbitrary binary data in a reliable way which is resistant to
161character-set transformations and other mail transport bogosity.
162.PP
163The
164.B url
165module does urlencoding and decoding, as defined in RFC1866.
166Urlencoding encodes arbitrary (but mostly text-like) name/value pairs as
167a text string containing no whitespace.
168.SS "Multiplexed I/O"
169The
170.B sel
171module provides a basis for doing nonblocking I/O in Unix systems. It
172provides types and functions for receiving events when files are ready
173for reading or writing, and when timers expire.
174.PP
175The
176.B conn
177module implements nonblocking network connections in a way which fits in
178with the
179.B sel
180system. It makes nonblocking connects pretty much trivial.
181.PP
182The
183.B selbuf
184module attaches to the
185.B sel
186system and sends an event when lines of text arrive on a file. It's
187useful when reading text from a network connection.
188.SH "SEE ALSO"
189.BR alloc (3),
190.BR base64 (3),
191.BR bits (3),
192.BR conn (3),
193.BR crc32 (3),
194.BR dspool (3),
195.BR dstr (3),
196.BR exc (3),
197.BR lbuf (3),
198.BR lock (3),
199.BR mdwopt (3),
200.BR quis (3),
201.BR report (3),
202.BR sel (3),
203.BR selbuf (3),
204.BR str (3),
205.BR sub (3),
206.BR sym (3),
207.BR tv (3),
208.BR url (3).
209.SH AUTHOR
210Mark Wooding, <mdw@nsict.org>