6 ms·

So...it wasn't really rand() at fault here, it was some reentrancy library that newlib uses... For some reason the blog lists the source for rand_r, to which t

by chrsig 5y ago

So...it wasn't really rand() at fault here, it was some reentrancy library that newlib uses... For some reason the blog lists the source for rand_r, to which the caller supplies the state rather than using global state. I wonder if they'll run into this with any of the non-reentrant C functions (strtok, I'm looking at you). It makes their conclusion of "we stopped using rand()" a bit wanting. I mean, it's great that they stopped using rand(), that's a good move, and pragmatic given their issue, it just feels like it's a really surface level conclusion.

raggi 5y ago
came here to raise the same thing, it's odd that this rand was allocating. it seems a little odd to be fixing reentry in rand() and not rand_r() when rand is already so bad anyway. I'm not sure what's worse between doing this reentrancy dance and dropping the taocp magic number accidentally if the static isn't seeded (as in musl). rand is bad, stop using rand was the right answer in any case.
piker 5y ago
To be fair they did say at the end they added a regression test to look for malloc calls in the binaries.