Gilles Chanteperdrix wrote: > Jan Kiszka wrote: > > Gilles Chanteperdrix wrote: > > > I would also prefer passing the bheaph_t** storage to bheap_init, and > > > conserve bheap_destroy (with a callback called with the bheap_t** > > > storage) in case the storage was dynamically allocated by the caller. > > > > Do you have a concrete usage scenario in mind where this would be > > required? I would rather bet that potential callers of bheap_destroy > > know very well when some buffer is to be released. Looks at bit like > > overkill unless someone has the real need to mix dynamically with > > statically allocated bheaps. > > Requesting a bheaph_t ** to be passed to bheap_init is type-safe and > would have caught the kind of mistake you have done.
But I also did not use the macro, which avoids such mistakes now. > bheap_destroy allow > setting the bheap_t structure to an invalid value which, in turn, allow > helping upper layers in catching invalid uses of the bheap after its > destruction. Ok, we could make bheap_destroy pop up under XENO_OPT_DEBUG. We may then also add assertions to the bheap functions themselves to check for invalid usage. > > It is a low price to pay to make the interface a bit safer. > The price is also larger code in every heap runtime function due to the additional indirection. I still vote for the combined structure and to give its allocation completely in user hand. Jan
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
