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.


Attachment: signature.asc
Description: OpenPGP digital signature

Xenomai-core mailing list

Reply via email to