Tidy uses a user provided allocator for all memory allocations.
More...
If this allocator is not provided, then a default allocator is used which simply wraps standard C malloc/free calls. These wrappers call the panic function upon any failure. The default panic function prints an out of memory message to stderr, and calls exit(2).
For applications in which it is unacceptable to abort in the case of memory allocation, then the panic function can be replaced with one which longjmps() out of the tidy code. For this to clean up completely, you should be careful not to use any tidy methods that open files as these will not be closed before panic() is called.
TODO: associate file handles with tidyDoc and ensure that tidyDocRelease() can close them all.
Calling the withAllocator() family ( tidyCreateWithAllocator, tidyBufInitWithAllocator, tidyBufAllocWithAllocator) allow settings custom allocators).
All parts of the document use the same allocator. Calls that require a user provided buffer can optionally use a different allocator.
For reference in designing a plug-in allocator, most allocations made by tidy are less than 100 bytes, corresponding to attribute names/values, etc.
There is also an additional class of much larger allocations which are where most of the data from the lexer is stored. (It is not currently possible to use a separate allocator for the lexer, this would be a useful extension).
In general, approximately 1/3rd of the memory used by tidy is freed during the parse, so if memory usage is an issue then an allocator that can reuse this memory is a good idea.
To create your own allocator, do something like the following:
typedef struct _MyAllocator {
...other custom allocator state...
} MyAllocator;
void* MyAllocator_alloc(
TidyAllocator *base,
void *block,
size_t nBytes)
{
MyAllocator *self = (MyAllocator*)base;
...
}
(etc)
MyAllocator_alloc,
MyAllocator_realloc,
MyAllocator_free,
MyAllocator_panic
};
myAllocator allocator;
allocator.base.vtbl = &MyAllocatorVtbl;
...initialise allocator specific state...
Although this looks slightly long winded, the advantage is that to create a custom allocator you simply need to set the vtbl pointer correctly. The vtbl itself can reside in static/global data, and hence does not need to be initialised each time an allocator is created, and furthermore the memory is shared amongst all created allocators.
Definition at line 224 of file tidy.h.
| struct _TidyAllocatorVtbl |
All functions here must be provided.
Definition at line 166 of file tidy.h.
Must support being called with NULL.
| _TidyAllocatorVtbl::void |
( |
TIDY_CALL * |
free | ) |
|
| _TidyAllocatorVtbl::void |
( |
TIDY_CALL * |
panic | ) |
|
Must support block == NULL. This function is not called if either alloc or realloc fails; it is up to the allocator to do this. Currently this function can only be called if an error is detected in the tree integrity via the internal function CheckNodeIntegrity(). This is a situation that can only arise in the case of a programming error in tidylib. You can turn off node integrity checking by defining the constant NO_NODE_INTEGRITY_CHECK during the build.
| void* _TidyAllocatorVtbl::block |
| ctmbstr _TidyAllocatorVtbl::msg |
| typedef void(TIDY_CALL * TidyFree) (void *buf) |
| typedef void*(TIDY_CALL * TidyMalloc) (size_t len) |
| typedef void(TIDY_CALL * TidyPanic) (ctmbstr mssg) |
| typedef void*(TIDY_CALL * TidyRealloc) (void *buf, size_t len) |
| Bool TIDY_CALL tidySetFreeCall |
( |
TidyFree |
ffree | ) |
|
| Bool TIDY_CALL tidySetMallocCall |
( |
TidyMalloc |
fmalloc | ) |
|
| Bool TIDY_CALL tidySetPanicCall |
( |
TidyPanic |
fpanic | ) |
|
| Bool TIDY_CALL tidySetReallocCall |
( |
TidyRealloc |
frealloc | ) |
|
1.8.9.1 
