Technically, they're probably ok -- nothing seems to actually use the prototype in sysent.c and we explicitly check the size in getentropy, so the return value will always fit in an int.  However, relying on such things does seem rather brittle, so it would be better to update these.  I'll post an update in a bit reflecting these.

I agree that we clamp it at the moment, so the return will happen to fit in whatever the type is declared as.
As for sysent.c, should the table be changed from SYSENT_CI to SYSENT_CL?

An earlier draft did language around request sizes, but then it was dropped.  I think it ends up exposing (and committing us to) too many implementation details if we were to try to document it.  We can always come back later and make stronger guarantees if we need to.

As the person who actually wrote the manual page (and the original code), I don't believe it makes sense to do so, mostly for the reasons Jason mentioned. If we have cases where we can do more in the future, having a fixed upper bound only hurts us. That said, I think the biggest thing that a consumer would really want was a guaranteed lower bound of I got this much data or I got nothing much in the fashion of getentropy(3C). That said, it's something we should probably do in another change with a lot more analysis of the getrandom(2) kernel interfaces to make sure we can actually honor that guarantee.