GeezerVisonThe World Wide Web, restored to 800 pixels of glory. |
| Home|About|Gaming cabinet|Archives|How it works|Starter sites |
GeezerVison is showing man.openbsd.org — ohash_init(3) - OpenBSD manual pages NAME
SYNOPSIS/* -lutil */
void
void
unsigned int
unsigned int
void *
void *
void *
void *
void *
unsigned int
DESCRIPTIONThese functions have been designed as a fast, extensible alternative to the usual hash table functions. They provide storage and retrieval of records indexed by keys, where a key is a contiguous sequence of bytes at a fixed position in each record. Keys can either be NUL-terminated strings or fixed-size memory areas. All functions take a pointer to an ohash structure as the h function argument. Storage for this structure should be provided by user code.
struct ohash_info {
ptrdiff_t key_offset;
void *data; /* user data */
void *(*calloc)(size_t, size_t, void *);
void (*free)(void *, void *);
void *(*alloc)(size_t, void *);
};
The offset field holds the position of the key in each record; the calloc and free fields are pointers to calloc(3) and free(3)-like functions, used for managing the table internal storage; the alloc field is only used by the utility function ohash_create_entry(3). Each of these functions are called similarly to their standard counterpart, but with an extra void * parameter corresponding to the content of the field data, which can be used to communicate specific information to the functions.
for (n = ohash_first(h, &i); n != NULL; n = ohash_next(h, &i)) do_something_with(n); 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.
STORAGE HANDLINGOnly p = (*info->calloc)(n, sizeof_record, info->data); /* copy data from old to p */ (*info->free)(old, info->data); It is the responsibility of the user memory allocation code to verify that those calls did not fail. If memory allocation fails,
THREAD SAFETYThe open hashing functions are not thread-safe by design. In
particular, in a threaded environment, there is no guarantee that a
"slot" will not move between a
Multi-threaded applications should explicitly protect ohash table access. SEE ALSODonald E. Knuth, The Art of Computer Programming, Vol. 3, pp. 506–550, 1973. STANDARDSThose functions are completely non-standard and should be avoided in portable programs. HISTORYThose functions were designed and written for OpenBSD make(1) by Marc Espie in 1999. |
| You are visitor 01402503 — GeezerVison does not store the pages you look up. Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required. |