[email protected] wrote: > [email protected] wrote: > >I have no strong opinion. I'm fine with either approach. It's such a > >silly program... > > > >As an aside, random -e has been completely broken (it's non-uniform) > >since forever. To fix -e, we should clamp denom to an integer between > >1 and 256, otherwise the truncation of the exit exit code to an 8-bit > >int introduces bias for numbers larger than 256 (that aren't powers of > >2). > > The program is broken in multiple ways: return value clamping, casting > from double to uint32_t, wrong error checking for putchar, lack of > warnings when compiling. > > What I don't understand is why such a wrong program has its place in > OpenBSD. Maybe it's historical reasons, who knows. But the fact that it > exists and it's badly written bothers me.
the games directory is a playground. It is low-risk place in our tree where someone can find some very old code and try to raise it to the standard of non-games code, and learn lessons. If they make a mistake, that's OK. If they learn from the mistakes and find some great idea, that's even better. A bunch of pledge and unveil experimentation happened in games, and some privdrop and privsep has also happened there. All which are incomplete. There is more which can be done there. It kind of demonstrates that very old software CAN adopt the security-focus changes we've been making. The ideas are pretty universal, and can even be applied to terribly old software. If all the software in our ecosystem was modern, there would be no place to practice and learn. And anyways, this directory is not in $PATH by default, so there is no risk.
