You're correct. However those sound like perfectly reasonable changes to me. gets(3) is a horrible API.
As defined by POSIX.1-2001:
> If a read error occurs, the error indicator for the stream shall be set, gets() shall return a null pointer, and set errno to indicate the error.
IMHO the least-unreasonable thing to do is to behave exactly as if a read error occurred, but programs that do use gets(3) are unlikely to check for errno anyway.
> The rand() function shall return the next pseudo-random number in the sequence.
The spec does not say what the sequence should look like, other than it's pseudorandom, so the exact sequence is implementation-dependent. You can't use it to e.g. seed a test run, a terrain generator, etc - and expect repeatable results across platforms, releases. (And I honestly can't think of another reasonable use case for deterministic output.) IMHO at that point you should define your own PRNG, it's about 8 lines of C.
But you're obviously correct, these are deviations.
The rand(3) thing isn't about repeatability across implementations. Normally if you call srand(3) with the same seed, you get the same sequence of numbers from rand(3). It's useful for testing and debugging. OpenBSD ignores srand(3) altogether. The reasoning is that there are enough cases of people improperly seeding the PRNG that it's worth breaking POSIX to mitigate possible vulnerabilities.
I personally don't have an issue with their choices - they're completely in line with OpenBSD's mission of producing a secure OS. I'd be less pleased to see that sort of thing in other systems like NetBSD, though.
As defined by POSIX.1-2001:
> If a read error occurs, the error indicator for the stream shall be set, gets() shall return a null pointer, and set errno to indicate the error.
IMHO the least-unreasonable thing to do is to behave exactly as if a read error occurred, but programs that do use gets(3) are unlikely to check for errno anyway.
> The rand() function shall return the next pseudo-random number in the sequence.
<https://pubs.opengroup.org/onlinepubs/007904875/download/> susv3/functions/rand.html
The spec does not say what the sequence should look like, other than it's pseudorandom, so the exact sequence is implementation-dependent. You can't use it to e.g. seed a test run, a terrain generator, etc - and expect repeatable results across platforms, releases. (And I honestly can't think of another reasonable use case for deterministic output.) IMHO at that point you should define your own PRNG, it's about 8 lines of C.
But you're obviously correct, these are deviations.