@@@ fltfmt wip
[mLib] / mLib.3.in
... / ...
CommitLineData
1.\" -*-nroff-*-
2.\"
3.\" mLib overview
4.\"
5.\" (c) 1999--2001, 2003, 2005, 2007, 2009, 2024 Straylight/Edgeware
6.\"
7.
8.\"----- Licensing notice ---------------------------------------------------
9.\"
10.\" This file is part of the mLib utilities library.
11.\"
12.\" mLib is free software: you can redistribute it and/or modify it under
13.\" the terms of the GNU Library General Public License as published by
14.\" the Free Software Foundation; either version 2 of the License, or (at
15.\" your option) any later version.
16.\"
17.\" mLib is distributed in the hope that it will be useful, but WITHOUT
18.\" ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
19.\" FITNESS FOR A PARTICULAR PURPOSE. See the GNU Library General Public
20.\" License for more details.
21.\"
22.\" You should have received a copy of the GNU Library General Public
23.\" License along with mLib. If not, write to the Free Software
24.\" Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307,
25.\" USA.
26.
27.\"--------------------------------------------------------------------------
28.so ../defs.man \" @@@PRE@@@
29.
30.\"--------------------------------------------------------------------------
31.TH mLib 3mLib "7 July 1999" "Straylight/Edgeware" "mLib utilities library"
32.\" @mLib
33.
34.\"--------------------------------------------------------------------------
35.SH NAME
36mLib \- library of miscellaneous utilities
37.
38.\"--------------------------------------------------------------------------
39.SH DESCRIPTION
40.
41The
42.B mLib
43library is a mixed bag of things which the author finds useful in large
44numbers of programs. As a result, its structure is somewhat arbitrary,
45and it's accreted extra bits over time rather than actually being
46designed as a whole. In the author's opinion this isn't too much of a
47hardship.
48.PP
49At the most granular level,
50.B mLib
51is split into `modules', each of which has its own header file and
52manual page. Sometimes there are identifiable `chunks' of several
53modules which fit together as a whole. Modules and chunks fit into
54`layers', each depending on the ones below it. The header file for
55module
56.I foo
57would be put in
58.BR <mLib/ \c
59.IR foo \c
60.BR .h> .
61.PP
62This description is a bit abstract, and
63.BR mLib ,
64as a result of its history, doesn't fit it as well as I might like.
65Even so, it's not too bad a model really.
66.PP
67The rest of this section describes the various chunks and layers.
68.
69.SS "Exception handling"
70Right at the bottom, there's a fairly primitive exception handling
71system. It's provided by the
72.BR exc (3)
73module, and stands alone. It's used mainly by the memory allocation
74modules to raise exceptions when there's no more memory to be had.
75.
76.SS "Memory allocation"
77The
78.BR arena (3)
79module provides an abstraction of memory allocation. By writing
80appropriate arena implementations, a client program can control where
81and how memory is allocated for various structures.
82.PP
83The
84.BR alloc (3)
85module provides simple veneers onto traditional memory allocation
86functions like
87.BR malloc (3)
88and
89.BR strdup (3)
90(although
91.B mLib
92doesn't actually depend on
93.B strdup
94being defined in the library) which raise exceptions when there's not
95enough memory left. These work through the
96.B arena
97layer, so that the caller can control memory allocation.
98.PP
99The
100.BR sub (3)
101module handles efficient allocation of small blocks. It allocates
102memory in relatively big chunks and divides the chunks up into small
103blocks before returning them. It keeps lists of differently-sized
104blocks so allocation and freeing is fast. The downside is that your
105code must know how big a block is when it's being freed.
106.PP
107The
108.B track
109module (not yet documented) is a simple memory allocation tracker. It
110can be handy when trying to fix memory leaks.
111.PP
112The
113.BR pool (3)
114module maintains resource pools which can manage memory and other
115resources, all of the resources held in a pool being destroyed along
116with the pool itself.
117.
118.SS "String handling"
119The
120.BR str (3)
121module provides some trivial string-manipulation functions which tend to
122be useful quite often.
123.PP
124The
125.BR dstr (3)
126module implements a dynamic string data type. It works quite quickly
127and well, and is handy in security-sensitive programs, to prevent
128buffer-overflows. Dynamic strings are used occasionally through the
129rest of the library, mainly as output arguments.
130.PP
131The
132.BR buf (3)
133module provides simple functions for reading and writing binary data to
134or from fixed-sized buffers.
135.PP
136The
137.BR dspool (3)
138module implements a `pool' of dynamic strings which saves lots of
139allocation and deallocation when a piece of code has high string
140turnover.
141.
142.SS "Program identification and error reporting"
143The
144.BR quis (3)
145module remembers the name of the program and supplies it when asked.
146It's used in error messages and similar things.
147.PP
148The
149.BR report (3)
150module emits standard Unixy error messages. It provides functions
151.B moan
152and
153.B die
154which the author uses rather a lot.
155.PP
156The
157.BR trace (3)
158module provides an interface for emitting tracing information with
159configurable verbosity levels. It needs improving to be able to cope
160with outputting to the system log.
161.
162.SS "Other data types"
163The
164.BR hash (3)
165module provides the basics for an extending hashtable implementation.
166Many different hashtable-based data structures can be constructed with
167little effort.
168.PP
169The
170.BR sym (3)
171module implements a rather good general-purpose extending hash table.
172Keys and values can be arbitrary data. It is implemented using
173.BR hash (3).
174.PP
175The
176.BR atom (3)
177module implements
178.IR atoms ,
179which are essentially strings with the property that two atoms have the
180same address if and only if they have the same text, so they can be used
181for rapid string comparisons. The
182.BR assoc (3)
183module implements a hash table which uses atoms as keys, thus saving
184time spent hashing and comparing hash keys, and the space used for the
185keys.
186.PP
187The
188.BR darray (3)
189module implements dynamically resizing arrays which support Perl-like
190stack operations efficiently.
191.
192.SS "Miscellaneous utilities"
193The
194.BR crc32 (3)
195module calculates CRC values for strings. It used to be used by the
196symbol table manager as a hash function.
197.PP
198The
199.BR unihash (3)
200module implements a simple but efficient universal hashing family. This
201is a keyed hash function which provides security against an adversary
202choosing input to a hash table deliberately to cause collisions.
203.PP
204The
205.BR lock (3)
206module does POSIX
207.BR fcntl (2)-style
208locking with a timeout.
209.PP
210The
211.BR env (3)
212module manipulates environment variables stored in a hashtable, and
213converts between the hashtable and the standard array representation of
214a process environment.
215.PP
216The
217.BR fdflags (3)
218module manipulates file descriptor flags in a fairly painless way.
219.PP
220The
221.BR fwatch (3)
222module allows you to easily find out whether a file has changed since
223the last time you looked at it.
224.PP
225The
226.BR lbuf (3)
227module implements a `line buffer', which is an object that emits
228completed lines of text from an incoming asynchronous data stream. It's
229remarkably handy in programs that want to read lines from pipes and
230sockets can't block while waiting for a line-end to arrive. Similarly,
231the
232.BR pkbuf (3)
233module implements a `packet buffer', which waits for packets of given
234lengths to arrive before dispatching them to a handler.
235.PP
236The
237.BR tv (3)
238module provides some macros and functions for playing with
239.BR "struct timeval" .
240.PP
241The
242.BR bits (3)
243module defines some types and macros for playing with words as chunks of
244bits. There are portable rotate and shift macros (harder than you'd
245think), and macros to do loading and storing in known-endian formats.
246values.
247.PP
248The
249.BR mdwopt (3)
250module implements a fairly serious options parser compatible with the
251GNU options parser.
252.PP
253The
254.BR testrig (3)
255module provides a generic structure for reading test vectors from files
256and running them through functions. I mainly use it for testing
257cryptographic transformations of various kinds.
258.
259.SS "Encoding and decoding"
260The
261.BR base64 (3)
262module does base64 encoding and decoding, as defined in RFC2045. Base64
263encodes arbitrary binary data in a reliable way which is resistant to
264character-set transformations and other mail transport bogosity. The
265.BR base32 (3)
266module does base32 encoding and decoding, as defined in RFC2938. This
267is a mad format which is needed for sha1 URNs, for no good reason. The
268.BR hex (3)
269module does hex encoding and decoding.
270.PP
271The
272.BR url (3)
273module does urlencoding and decoding, as defined in RFC1866.
274Urlencoding encodes arbitrary (but mostly text-like) name/value pairs as
275a text string containing no whitespace.
276.
277.SS "Multiplexed I/O"
278The
279.BR sel (3)
280module provides a basis for doing nonblocking I/O in Unix systems. It
281provides types and functions for receiving events when files are ready
282for reading or writing, and when timers expire.
283.PP
284The
285.BR conn (3)
286module implements nonblocking network connections in a way which fits in
287with the
288.B sel
289system. It makes nonblocking connects pretty much trivial.
290.PP
291The
292.BR selbuf (3)
293module attaches to the
294.B sel
295system and sends an event when lines of text arrive from a file. It's
296useful when reading text from a network connection. Similarly,
297.BR selpk (3)
298sents events when packets of given sizes arrive from a file.
299.PP
300The
301.BR sig (3)
302module introduces signal handling into the multiplexed I/O world.
303Signals are queued until dispatched through the normal
304.B sel
305mechanism.
306.PP
307The
308.BR ident (3)
309module provides a nonblocking ident (RFC931) client. The
310.BR bres (3)
311module does background hostname and address resolution.
312.
313.\"--------------------------------------------------------------------------
314.SH "SEE ALSO"
315.
316.BR alloc (3),
317.BR assoc (3),
318.BR atom (3),
319.BR base64 (3),
320.BR bits (3),
321.BR buf (3),
322.BR bres (3),
323.BR conn (3),
324.BR crc32 (3),
325.BR darray (3),
326.BR dspool (3),
327.BR dstr (3),
328.BR env (3),
329.BR exc (3),
330.BR fdflags (3),
331.BR fwatch (3),
332.BR hash (3),
333.BR ident (3),
334.BR lbuf (3),
335.BR lock (3),
336.BR mdwopt (3),
337.BR pkbuf (3),
338.BR quis (3),
339.BR report (3),
340.BR sel (3),
341.BR selbuf (3),
342.BR selpk (3),
343.BR sig (3),
344.BR str (3),
345.BR sub (3),
346.BR sym (3),
347.BR trace (3),
348.BR tv (3),
349.BR url (3).
350.
351.\"--------------------------------------------------------------------------
352.SH AUTHOR
353.
354Mark Wooding, <mdw@distorted.org.uk>
355.
356.\"----- That's all, folks --------------------------------------------------