Hi Collin, > I've committed these two patches adjusting idpriv-drop and > idpriv-droptemp which previously stored the result of getuid () and > getgid () in an 'int'.
The first patch is obviously fine. The second patch makes the assumption that uid_t and gid_t are at least 32-bits wide. I had written the code that way because on some systems (SunOS 4 IIRC, older IRIX, and Linux [1]) uid_t and gid_t had been 'unsigned short', and thus a comparison of an 'unsigned short' with -1 always returned false. But nowadays, for more than 20 years, they are 32-bit. > For other modules where an ID is used as the result to printf it is > often casted to an int. Should I change those to intmax_t? I feel like > that would be the most portable way. This would be overkill. uid_t changed from 16 bits to 32 bits because it had been a practical problem: some internet providers provided shell access to servers to more than 65000 customers. There is no practical problem with 32 bits; no one needs more than 2 billion users or groups on a single machine. Cf. also the accepted answer of [2]. There's no point in addressing hypothetical problems that most likely will never exist. Bruno [1] https://docs.kernel.org/admin-guide/highuid.html [2] https://stackoverflow.com/questions/20533606/
