These ports were added 17 years ago in this commit https://github.com/FreeRTOS/FreeRTOS-Kernel/commit/504382bcb84c2c8d774d7fa2abd3c5da6b4de1ee and are the only ones that implement pvPortRealloc. It's implemented here by calling stdlib realloc. I wanted to verify whether this is correct? I think this would only work as expected for heap3 (it wraps and calls the stdlib malloc and free). For other heaps I think there would be issues since realloc would create a pointer that gets passed to heap's vPortFree, which it wouldn't know how to free.
Maybe a good legacy-friendly fix would be to statically assert that heap_3 is being used for the AVR32_UC3 port?
Your analysis seems correct. This will not work with the heaps managed by FreeRTOS itself. And thus would only work with the heap_3 implementation using the stdlib.
https://github.com/FreeRTOS/FreeRTOS-Kernel/blob/4732b96dba05e2eeaeaec795977ab0a054cce065/portable/GCC/AVR32_UC3/port.c#L203
https://github.com/FreeRTOS/FreeRTOS-Kernel/blob/4732b96dba05e2eeaeaec795977ab0a054cce065/portable/IAR/AVR32_UC3/port.c#L170
These ports were added 17 years ago in this commit https://github.com/FreeRTOS/FreeRTOS-Kernel/commit/504382bcb84c2c8d774d7fa2abd3c5da6b4de1ee and are the only ones that implement's
pvPortRealloc
. It's implemented here by calling stdlibrealloc
. I wanted to verify whether this is correct? I think this would only work as expected for heap3 (it wraps and calls the stdlibmalloc
andfree
). For other heaps I think there would be issues sincerealloc
would create a pointer that gets passed to heapvPortFree
, which it wouldn't know how to free.Maybe a good legacy-friendly fix would be to statically assert that heap_3 is being used for the AVR32_UC3 port?