zephyr: alloc: Use generic is_heap_pointer for shared and L3 heaps

[softwarecki]

This pull request replaces specialized heap pointer checks with the generic is_heap_pointer utility for both shared and L3 heaps. The change removes the is_shared_buffer_heap_pointer and is_l3_heap_pointer functions, simplifying the memory handling path and reducing code duplication. By relying on a common utility, the implementation becomes more consistent and easier to maintain without altering existing behavior.

[Copilot]

Pull request overview

This PR refactors the heap pointer validation logic by replacing specialized functions (is_shared_buffer_heap_pointer and is_l3_heap_pointer) with the generic is_heap_pointer utility. The change eliminates code duplication while maintaining identical functionality for memory deallocation checks in both shared and L3 heaps.

Key Changes:

• Removed two specialized heap pointer check functions in favor of the generic is_heap_pointer
• Updated rfree() to use is_heap_pointer for both L3 and shared buffer heap validation
• Added initialization of init_mem and init_bytes fields in heap structures to support the generic pointer check

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[lyakh]

good to use a single function of course, but relying on .init_mem and .init_bytes is a bit concerning, a comment in zephyr/include/zephyr/sys/sys_heap.h says about them:

Would be good to clean this up and put the two values somewhere else

But I guess if they do get removed, we'll store the values elsewhere

[softwarecki]

@lyakh

/* Note: the init_mem/bytes fields are for the static initializer to
 * have somewhere to put the arguments.  The actual heap metadata at
 * runtime lives in the heap memory itself and this struct simply
 * functions as an opaque pointer.  Would be good to clean this up and
 * put the two values somewhere else, though it would make
 * SYS_HEAP_DEFINE a little hairy to write.
 */

This comment was added more than 6 years ago (zephyrproject-rtos/zephyr@aa42277) and it seems unlikely that these fields will be replaced in the future. They are still used by heaps created with the SYS_HEAP_DEFINE macro. The author's concern was probably that these fields are only used during initialization and are unnecessary at runtime. If they start being used at runtime, the discomfort suggesting their removal will disappear.

[tmleman]

LGTM

[kv2019i]

Only known fails in CI, proceeding with merge.