[Feature] Support pvPortRealloc #1315

[skb666]

Description

This PR introduces a new API pvPortRealloc to FreeRTOS, providing dynamic memory reallocation similar to the standard C library's realloc. With configSUPPORT_HEAP_REALLOC enabled, applications can now resize heap-allocated memory blocks at runtime, either shrinking, expanding in place, or reallocating with data migration when needed.

Key Changes:

• Added the pvPortRealloc API in portable/MemMang/heap_4.c and heap_5.c.
• Added the configuration macro configSUPPORT_HEAP_REALLOC (default 0, must be 1 to enable realloc support).
• Updated FreeRTOSConfig.h and checked for correct configuration use.
• Critical sections and heap integrity checks are enforced throughout realloc logic.
• Follows realloc semantics:
  • NULL pointer behaves like malloc.
  • Size 0 behaves like free.
  • Tries in-place expand or shrink when possible; otherwise allocates a new block, copies data, and frees the old one.

Test Steps

1. Enable configSUPPORT_HEAP_REALLOC and ensure dynamic allocation is also enabled.
2. Build with either heap_4.c or heap_5.c.
3. Call pvPortRealloc to:
   • Expand, shrink, and reduce memory blocks.
   • Pass NULL as input.
   • Pass size 0.
   • Test fragmentation and edge cases (failing allocation, invalid pointers).
4. Validate heap stats and application logic remain correct.

Checklist:

• I have tested my changes. No regression in existing tests.
• I have modified and/or added unit-tests to cover the code changes in this Pull Request.

Related Issue

#1315

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[AniruddhaKanhere]

Hello @skb666,

Thank you for taking the time to contribute to the FreeRTOS-kernel.

I have some comments/questions about your PR. Can you please take a look and let me know what you think?

[AniruddhaKanhere]

Suggested change

	#error configSUPPORT_HEAP_REALLOC cannot be used without dynamic allocation, but configSUPPORT_HEAP_REALLOC is not set to 1.
	#error configSUPPORT_HEAP_REALLOC cannot be used without dynamic allocation, but configSUPPORT_DYNAMIC_ALLOCATION is not set to 1.

[AniruddhaKanhere]

To adhere to MISRA rule 15.5, FreeRTOS doesn't use multiple return statements in a single function.
We'd need to refactor this a bit to accommodate that.

[AniruddhaKanhere]

Would there not be a 4th case?

----------------------------------------------------------------------------------------------
|  \\\\ block full \\\\  |    free block   |    Current block  |    \\\\\\ block full \\\\\\ |      
----------------------------------------------------------------------------------------------

free block is 200 bytes long, the current block is 300 bytes long, and we call pvRealloc with size 400. Ideally, it would fit by merging the current block with the free block and moving data forward.

But in the algorithm that you propose, we are ignoring that possibility altogether.

Let me know if I am missing something.

[AniruddhaKanhere]

See my comments in heap_4 about multiple return statements