p .Fn ohash_init initializes the table to store roughly 2 to the power .Fa size elements. .Fa info holds the position of the key in each record, and two pointers to .Xr calloc 3 and .Xr free 3 Ns -like functions, to use for managing the table internal storage.
p .Fn ohash_delete frees storage internal to .Fa h . Elements themselves should be freed by the user first, using for instance .Fn ohash_first and .Fn ohash_next .
p .Fn ohash_lookup_interval and .Fn ohash_lookup_memory are the basic look-up element functions. The hashing function result is provided by the user as .Fa hv . These return a .Qq slot in the ohash table .Fa h , to be used with .Fn ohash_find , .Fn ohash_insert , or .Fn ohash_remove . This slot is only valid up to the next call to .Fn ohash_insert or .Fn ohash_remove .
p .Fn ohash_lookup_interval handles string-like keys. .Fn ohash_lookup_interval assumes the key is the interval between .Fa start and .Fa end , exclusive, though the actual elements stored in the table should only contain NUL-terminated keys.
p .Fn ohash_lookup_memory assumes the key is the memory area starting at .Fa k of size .Fa s . All bytes are significant in key comparison.
p .Fn ohash_find retrieves an element from a slot .Fa i returned by the .Fn ohash_lookup* functions. It returns .Dv NULL if the slot is empty.
p .Fn ohash_insert inserts a new element .Fa p at slot .Fa i . Slot .Fa i must be empty and element .Fa p must have a key corresponding to the .Fn ohash_lookup* call.
p .Fn ohash_remove removes the element at slot .Fa i . It returns the removed element, for user code to dispose of, or .Dv NULL if the slot was empty.
p .Fn ohash_first and .Fn ohash_next can be used to access all elements in an ohash table, like this: d -literal -offset indent for (n = ohash_first(h, &i); n != NULL; n = ohash_next(h, &i)) do_something_with(n); .Ed
p .Fa i points to an auxiliary unsigned integer used to record the current position in the ohash table. Those functions are safe to use even while entries are added to/removed from the table, but in such a case they don't guarantee that new entries will be returned. As a special case, they can safely be used to free elements in the table.
p .Fn ohash_entries returns the number of elements in the hash table. .Sh STORAGE HANDLING Only .Fn ohash_init , .Fn ohash_insert , .Fn ohash_remove and .Fn ohash_delete may call the user-supplied memory functions. It is the responsibility of the user memory allocation code to verify that those calls did not fail.
p If memory allocation fails, .Fn ohash_init returns a useless hash table. .Fn ohash_insert and .Fn ohash_remove still perform the requested operation, but the returned table should be considered read-only. It can still be accessed by .Fn ohash_lookup* , .Fn ohash_find , .Fn ohash_first and .Fn ohash_next to dump relevant information to disk before aborting. .Sh THREAD SAFETY The open hashing functions are not thread-safe by design. In particular, in a threaded environment, there is no guarantee that a .Qq slot will not move between a .Fn ohash_lookup* and a .Fn ohash_find , .Fn ohash_insert or .Fn ohash_remove call.
p Multi-threaded applications should explicitly protect ohash table access. .Sh SEE ALSO .Xr ohash_interval 3 .Rs .%A Donald E. Knuth .%B The Art of Computer Programming .%V Vol. 3 .%P pp 506-550 .%D 1973 .Re .Sh STANDARDS Those functions are completely non-standard and should be avoided in portable programs. .Sh HISTORY Those functions were designed and written for .Ox .Xr make 1 by Marc Espie in 1999.