Is there a particular reason why the stack overflow check (configCHECK_FOR_STACK_OVERFLOW > 1) now only checks for the 16 last bytes of stack (4 x uint32_t) as opposed to 20 bytes in previous versions?
And I see when portSTACK_GROWTH > 0, it still checks for 20 bytes with the earlier memcmp() usage. Intended?
I find this additional stack protection level useful and worth the cost. However, in effect it actually reduces the available stack; because if to be useful one has to implement vApplicationStackOverflowHook() that probably should show some sort of warning and halt/reboot if using that last part of the stack.
If I were to suggest something: The additional 16 (or 20) bytes this feature uses of the stack, should be added (when this feature is enabled) to stack allocation when creating stack. Simply because it is not really available for use. However, I see that it may be a bit of a consistency conflict in upcoming support for static tasks stacks; where freeRTOS would not be able to control this.
The discussion on whether to check for 16 or 20 (or another number) last bytes can lead to an endless discussion, as none of the stack checks are 100% safe. The reason I asked is that I am making use of that knowledge when displaying unused stack amount for tasks; not including that buffer zone. In order to not give a false impression that more bytes are available than there actually is. (I trigger a controlled message and reboot if detecting writes into that zone.) But the knowledge of the size of the buffer zone is not an exported item, and thus I need to (re)define it manually outside FreeRTOS. That is why I was a bit interested.
Why is the old way with memcmp (20 bytes) still used on stacks that grows upwards? Not that I think I have ever used such a target…