Updated ps_get_owner() to return a stringified uid if process owner name is not set.

[kosak]

In this interface I can't find igor's comment to reply to, so I'll comment right here.

• The buffer was perfectly fine — because snprintf was used, the value might be truncated, but would never overflow. Indeed. I was worried about truncation. I never said I was worried about overflow. My change was intended to fix the truncation problem. Why do you not care about the truncation problem?
• strtoul produces a 32-bit value, and the "%lu" format assumes that as well, so %lu will never result in more than 10 decimal digits. No, the format specifiers do not talk about bits. %lu means unsigned long and it needs to take an argument of type unsigned long. It's not correct to muddle C types with the bit lengths that they happen to be defined as right now in 2017 on your platform. It is also not correct, to assume that things will work because your format specifier represents a type "no smaller than" the size of your argument. It's not even cool, from a pedantic perspective, so far as I know, to pass a signed type to a format specifier that expects an unsigned type of the same size. And by the way, even by that argument, since %lu is unsigned long, and since unsigned long is going to be 64 bits on the machine you're sitting at, I don't know why you're talking about 32 bits.
• If you were worried that uid_t would be larger than 32 bits in some cases, you could have used something like sizeof(uid_t)/3+1 as the static size of the array. Yes, I was trying to defend against that, but also was trying to not make the code look excessively pedantic. So the point of my change, was to use a "worst case" type like unsigned long which would give lots of breathing room (we will be dead before sizeof(uid_t) > sizeof(unsigned long)). Put another way, I felt the original size (5 + 1) was definitely not future-proof, but assuming unsigned long would be good enough. A solution like char buffer[sizeof(uid_t)/3+1] is also ok with me, though I admit it seems a little pedantic (there's no performance advantage to getting the buffer size exactly right). But I would be fine with that and also fine with char buffer[128].

I think it's a little chaotic to whipsaw this code back and forth like this. I think the strtoul with unsigned long was the best version. I don't know why you (igor) would recommend going back to the atoi version. I'm happy to continue to discuss this if my input is welcome (I'm also happy with the opposite of that statement) so let me know if I should continue. But personally I'd rather discuss it as a discussion, rather than the ObamaCare style repeal-and-replace approach that we're using now. 😸

[kosak]

PS I like @igorpeshansky's suggestion result = strndup (line + 5, uid_end - line - 5); I think that's the awesomest because it avoids all this snprintf and buffer size drama altogether.

[rbuskens]

Reverted back to using unsigned long as a worst-case assumption to give us lots of breathing room / future-proofing. Updated the code to avoid the buffer size drama altogether.

[igorpeshansky]

@kosak For the record, I've never suggested reverting to atoi. :-) I was also typing these on a phone while riding on a crowded train, so some context got mixed up (e.g., the "you" in "if you were worried..." referred to Rick and not Corey). I think the whole "repeal-and-replace" exchange was Rick being somewhat overeager to apply every comment as it appeared, rather than waiting for the dust to settle. That said, your input is definitely appreciated.

[rbuskens]

+1 to what Igor wrote, Corey!

[kosak]

Ah, ok. Thanks Igor. (and I wish I knew how to reply to a comment here). I definitely was getting confused by all the changes (and my aging brain only holds about 3 bits of information any more), so thanks for the clarification! And I'm always happy to drop in via parachute.

[igorpeshansky]

LGTM :shipit: