3 ms·
Something as important as "uid" should be "const".
by jorangreef 6y ago
Something as important as "uid" should be "const".
- brongondwana 6y agoI mean... my first reading of that is "what a dumb idea, the reason it isn't const is that there are legit reasons to switch userid". But then I have used exactly this pattern, and it looks something like: struct protected_stuff { int userid; ... }; void set_userid(const struct protected_stuff prot, int newuserid) { struct protected_stuff backdoor = (struct protected_stuff *)prot; backdoor->userid = newuserid; } and then the compiler complains if you go fiddling with userid outside this function where you deliberately opened a backdoor to write to it. (and you can wrap pragmas around that function to turn off warnings).
- londons_explore 6y agoCompilers will produce slower code for this construction.
- brongondwana 6y agoThe nice thing is, it's a pretty rare call hopefully, so that's not a big deal so long as they aren't slowing down the much more common reads.
- kryptiskt 6y agoIf you're switching users in a hot loop you have other problems.
- jorangreef 6y agoYep... there are ways to make it happen.
- grishka 6y agoThere are legitimate reasons to change the uid at runtime. For example, some server software starts as root and then drops to a less-privileged user. Android relies on this too, zygote, the fully-initialized "blank" runtime process, runs as root and gets forked and changes uid to the corresponding unprivileged user whenever an app is launched.
- jorangreef 6y agoSure, and I don't disagree that uid might need to change at runtime, but here we're talking about a struct field being const.