The article contains a fair bit of fluff that may be aimed at developers without familiarity with embedded systems or I guess C, I'm not exactly sure what's with the tone but the short of it is:
- They've got an embedded system with all static allocation (they do mention having a dynamic allocator though)
- They've recently found a stack corruption crash which was traced back to rand() calling malloc() which is both unexpected and also malloc should never be called in the system at all
- They traced it back to their usage of newlibc configured to add reentant suppose for c functions that don't don't support it, and this support uses malloc, so when they call rand() this results in a call to malloc()
- A recent tooling update caused them to be using newlibc built this way; they previously were using newlibc configured without this feature
- Their solution is to not use rand() and instead use a different prng, and to write a tool that detects use of malloc() and fails the build
- They've got an embedded system with all static allocation (they do mention having a dynamic allocator though)
- They've recently found a stack corruption crash which was traced back to rand() calling malloc() which is both unexpected and also malloc should never be called in the system at all
- They traced it back to their usage of newlibc configured to add reentant suppose for c functions that don't don't support it, and this support uses malloc, so when they call rand() this results in a call to malloc()
- A recent tooling update caused them to be using newlibc built this way; they previously were using newlibc configured without this feature
- Their solution is to not use rand() and instead use a different prng, and to write a tool that detects use of malloc() and fails the build