Callback functions can be added to mempools for initializing objects and for freeing objects and user data. If the routine called to do this is called after objects have been created, There will be uninitialized objects that have either been allocated or are on the free list awaiting allocation. This might lead to obscure errors when the objects are operated on by user code or are when they are freed.
Several possible fixes are possible:
- Merge callback specification into the mempool constructor operations, precluding the error. This would remove the visible
cork_mempool_set_callbacks function from the interface and might break existing, arguably correct, uses. It also could lead to a proliferation of interfaces if options with and without callbacks are supplied along with the present variations on element size / type and block size.
- Introduce a test into
cork_mempool_set_callbacks that will raise an error and abort the program if it is called after any entities have been allocated, i.e. after the block chain pointer is non NULL. This would change the behavior of potentially erroneous programs, but would provide a clear indication of the problem to the user.
- Change the documentation to warn that calling
cork_mempool_set_callbacks after a block has been allocated creates an undefined behavior and possible program failures during execution. This is the easiest to do, but provides the least protection for the user, expecially users who do not regularly RTFM or check it for updates.
Callback functions can be added to mempools for initializing objects and for freeing objects and user data. If the routine called to do this is called after objects have been created, There will be uninitialized objects that have either been allocated or are on the free list awaiting allocation. This might lead to obscure errors when the objects are operated on by user code or are when they are freed.
Several possible fixes are possible:
cork_mempool_set_callbacksfunction from the interface and might break existing, arguably correct, uses. It also could lead to a proliferation of interfaces if options with and without callbacks are supplied along with the present variations on element size / type and block size.cork_mempool_set_callbacksthat will raise an error and abort the program if it is called after any entities have been allocated, i.e. after the block chain pointer is nonNULL. This would change the behavior of potentially erroneous programs, but would provide a clear indication of the problem to the user.cork_mempool_set_callbacksafter a block has been allocated creates an undefined behavior and possible program failures during execution. This is the easiest to do, but provides the least protection for the user, expecially users who do not regularly RTFM or check it for updates.