- United States
- https://bancino.net
- Joined on
2024-09-14
Oh nevermind, I see that the default behavior of this function is to set it to the user's own name.
I think we should set these parameters instead of having them be NULL
. The from
should be the user, and the reason
can just be hard-coded if necessary.
Fair enough, I'm good with that. It doesn't look bad by any means, the code is still readable. Everyone has their own style and I have no real problems with this one.
This looks pretty good. I will read the code more closely and test it when I have time. In the meantime, take a look at my comments and see what you feel is relevant. If you disagree with…
Is a separate function really necessary? Shouldn't we just modify UserDeactivate()
to take the additional params?
Is there a reason for declaring a variable here instead of just passing the string literal into MatrixErrorCreate()
?
This shouldn't be necessary. It should suffice to just UserUnlock()
here without first checking for NULL
, because UserUnlock()
should have a NULL
check in it already. I am going off of memory on that one, but if I'm wrong, UserUnlock()
should have this check instead.
Interesting. Let's take a look at the official POSIX standard: https://bancino.net/mirror/susv4-2018/basedefs/limits.h.html. It appears that HOST_NAME_MAX
is a runtime invariant that may be…
Good point. And honestly, this is kind of more wishful thinking for the time being, I might not ever actually get around to doing this. The current method is at no risk of going away any time…