A lot of “embedded” libcs do some pretty sketchy things; frustration with this sort of thing is what prompted the development of musl. I imagine given its dependency on a linux kernel it wouldn’t work in the kind of environments the author is dealing with, but fwiw here’s rand.c:

#include <stdlib.h>
#include <stdint.h>

static uint64_t seed;

void srand(unsigned s)
{
	seed = s-1;
}

int rand(void)
{
	seed = 6364136223846793005ULL*seed + 1;
	return seed>>33;
}

User with the username “nomemory” submits a post about an unexpected malloc. Hmmm. ;)

Good article though, I just thought the coincidence was amusing.

More generally: any libc function may call malloc. If this matters to you, then you should look at the libc internals and audit any function that you care about. Folks that ship a libc need to think about this in a few places. For example, FreeBSD libc uses jemalloc, which uses locks to protect some data structures, but the locks call malloc and so have their own bootstrapping path.

BTW, using rand is a bad idea since some implementations of it return extremely poor quality results. Use random instead. From the Linux man page:

   on older rand() implementations, **and on current
   implementations on different systems**, the lower-order bits are
   much less random than the higher-order bits.  Do not use this
   function in applications intended to be portable when good
   randomness is needed.  (Use random(3) instead.)

(Emphasis mine)

Also known as, “why implicit global state will always fuck you”.