malloc is supposed to return NULL when no memory is available.Please see: http://www.cplusplus.com/reference/cstdlib/malloc/For embedded applications, a trap on out-of-memory would be better!In no case is returning a pointer outside the heap acceptable.

As shown in this example, the default heap size of 1kB (for a processor with 256kB RAM!)in K64F example is too small for even a trivial RTL use, even before the application tries to use malloc.NXP examples should set sensible default heap size!

Numerous examples from Freescale/NXP set up heap incorrectly for newlib.Examples for FreeRTOS also do not configure FreeRTOS correctly (if you are using anything requiring heap, for example printf using floating point).

Yes you are right, malloc doesn't return NULL pointer when it overrun the heap size. I would not expect it, but after analyzing different situations it showed up, that malloc() returns NULL pointer only if there is not enough space neither in HEAP nor in STACK. I found this discussion on StackOverflow forum: http://stackoverflow.com/questions/39113658/when-does-malloc-return-null-in-a-bare-metal-environment They are talking about the HEAP and STACK collision, what could be related with this problem. Although, i am not sure if we can talk about collision even if both (STACK and HEAP) address ranges are managed. For example if i define an local array with 10 integers it will occupy cca 40-48 bytes at the top of the STACK. It means that this part of stack is not available for dynamic allocation and malloc() returns NULL if you try to allocate address space bigger than HEAP+STACK-48bytes. In my project 0x400 + 0x500 - 48bytes(mentioned array) - other local variables. This is the reason why i think that malloc function works safely and it cannot happen that the dynamic allocation will overwrite some variables in stack.

The point is what is 'reasonable' in one project is dangerous in an other.

In my view the correct default behavior for any tool set is always start with heap size of zero and malloc and friends return NULL. This forces the user to determine and set an appropriate heap size for their project then adjust the linker script as required.

Numerous examples from Freescale/NXP set up heap incorrectly for newlib.Examples for FreeRTOS also do not configure FreeRTOS correctly (if you are using anything requiring heap, for example printf using floating point).